GDPR and Privacy by Design in Code Review with Claude

1. Privacy by design as a technical obligation, not an option

Article 25 of the GDPR requires that data protection be ensured through technical design and through privacy-friendly default settings, starting from the very first design decision rather than added on afterward. In practice this means a development team carries technical co-responsibility for a new feature not processing, storing, or transmitting more personal data than is required for its specific purpose.

The everyday challenge is that this requirement rarely appears explicitly in a ticket. A feature request like add an export function for order history contains, on its own, no hint that purpose limitation, retention period, and a deletion concept also need to be thought through. This is exactly where a systematic code review with Claude can help surface these aspects routinely instead of leaving them to chance.

2. Surfacing missing pseudonymization and anonymization

A recurring pattern is personal data being processed or logged in plain text in places where pseudonymization would be technically possible, for example in analytics events, error logs, or debug output. Claude can be specifically instructed to identify every spot where fields like email address, name, or IP address flow into a logging statement, an analytics event, or an external API call without prior pseudonymization.

Particularly revealing is searching for log statements that output entire objects, for example a user object inside exception handling, instead of only the specific, non-personal fields actually needed for debugging. This pattern often arises unintentionally when an entire object gets logged for debugging purposes during development and the line stays in the code after the work is finished.

# Claude Code: specifically search for unpseudonymized personal data
claude "Search src/ for log, analytics, and error statements that contain
fields like email, name, ip_address, phone, or similar personal data
in plain text. List file, line, and the affected field, and suggest
a pseudonymization or hashing approach for each."

3. Finding excessive or missing retention periods in code

Article 5 of the GDPR requires storage limitation: personal data may only be kept for as long as its specific purpose requires. In code, a violation of this principle rarely shows up as an obvious bug but usually as an absence: a database table with no expiry logic whatsoever, a missing cleanup cron job, or a soft-delete flag that gets set without an actual deletion ever following.

During a data model review, Claude can be asked specifically which tables contain personal data and whether any deletion logic for those tables exists in the surrounding code, migrations, or scheduled jobs. This often reveals that a created_at field exists, but not a single place in the code ever deletes anything based on it, a clear sign that storage limitation was never actually implemented.

4. Checking deletion routines fully: don't forget cascades and backups

An existing deletion function alone does not guarantee complete deletion. Referenced records frequently remain in linked tables, caching layers, search indexes, or asynchronous event streams because the deletion cascade was implemented incompletely. Claude can be instructed to start from a deletion function and identify every other place in the code where the same entity is duplicated, cached, or replicated into another system.

An often overlooked area is backups and export files that live outside the regular data model and are therefore never captured by a deletion routine at all. Even though Claude cannot independently audit backup strategies, a targeted question during review helps make this gap visible in the first place, so it can then be addressed organizationally.

5. A concrete prompt template for the GDPR review

For a repeatable review, a fixed prompt structure that systematically answers the same four questions per pull request is worthwhile: which personal data is newly processed? Is pseudonymization technically possible and implemented? Is a recognizable retention period in place? Is the change covered by an existing deletion routine? The following template can be turned directly into a slash command for Claude Code.

# .claude/commands/gdpr-review.md stored as a slash command
claude "/gdpr-review $ARGUMENTS"

# Content of gdpr-review.md:
# Analyze the diff for the following four points:
# 1. List new or changed personal data fields.
# 2. Check whether pseudonymization/anonymization would be technically possible.
# 3. Check whether a retention period is recognizable in the data model or code.
# 4. Check whether an existing deletion routine covers the new fields/tables.
# Output as a table with field, location, risk, and technical suggestion.

6. The boundary to legal advice: what Claude cannot do

As useful as technical pointers are, Claude cannot provide legal advice and cannot make a binding statement on whether a specific data processing activity is lawful under the GDPR. Questions about the legal basis under Article 6, the admissibility of a legitimate interest assessment, or the appropriateness of a retention period for a particular business purpose require a legal assessment by a data protection officer or a specialized lawyer.

The sensible framing is therefore a clear division of labor: Claude identifies technical starting points and surfaces them during code review, while the legal classification, whether a found pattern actually constitutes a violation and which retention period is specifically appropriate, stays with the legal department or outside counsel. This split should be communicated explicitly within the team so a technical pointer is never mistaken for legal sign-off.

7. Integration into the existing review process

So a GDPR review does not need to be triggered manually on every single pull request, a label or path filter works well: changes to directories containing user data, payment information, or communication data automatically trigger the additional review step, while purely frontend changes without data relevance do not need to go through it. This keeps the extra effort scoped specifically to the areas where it actually matters.

Results should be documented rather than merely discarded in the pull request comment, especially for larger initiatives that will need a formal data protection impact assessment later anyway. An archived Claude review can serve as technical groundwork that a data protection officer draws on during that impact assessment instead of having to start the technical analysis completely from scratch.

8. A real-world example: unbounded retention in a support table

In a realistic scenario, a pull request adds a new support_tickets table storing name, email address, and the full message history of a support case. Neither the data model nor the accompanying code specifies how long this data should be retained. A standard SAST scanner reports no finding here because everything is syntactically correct.

During a targeted GDPR review, Claude can name exactly this missing time boundary and concretely suggest adding a resolved_at field and implementing a scheduled job that automatically deletes or anonymizes closed tickets after a period the team defines. The specific retention length still needs to be set based on business and legal judgment, but the technical solution proposal shortens the path there considerably.

9. Checklist for development teams and conclusion

A compact everyday checklist: for every new table with personal data, check whether a retention period is defined. For every new logging or analytics call, check whether pseudonymization would be possible. For every new deletion function, check whether caches, search indexes, and linked tables are covered too. These three points anchor well as a recurring Claude prompt within the review workflow.

Claude does not replace a data protection officer or legal advice, but it noticeably shortens the path from a vague sense that a feature might be relevant under data protection law to a concrete, technically grounded list of findings. It is exactly this groundwork that makes privacy by design practically actionable in everyday development, instead of leaving it as an abstract legal principle at the ticket level.

10. Summary

11. FAQ: GDPR and Privacy by Design in Code Review: The Essentials at a Glance