Mapping Skills to GDPR Articles

GDPR Requirement Relevant Article Claude Skill Consent management Art. 7 tdd, frontend-design Data portability Art. 20 pdf, xlsx Right to erasure Art. 17 tdd Data minimization ...

GDPR Data Privacy Implementation (2026)

Last updated: April 17, 2026

Implementing GDPR compliance in software projects requires systematic attention to data handling, user consent, and privacy controls. Claude Code provides capabilities that help developers build privacy-conscious applications, though ultimate compliance responsibility rests with the development team. This checklist covers practical steps for integrating data privacy protections into your workflow using Claude Code and its ecosystem of skills.

Foundation: Understand Data Flow Before Coding

Before writing any code, map how personal data moves through your system. Document what data you collect, where it travels, who accesses it, and how long you retain it. The supermemory skill helps maintain persistent context across sessions, allowing you to build a comprehensive data inventory that persists throughout the project lifecycle.

Create a simple data flow document:

User Data Inventory
| Data Type | Source | Storage | Access | Retention |
|-----------|--------|---------|--------|-----------|
| Email | Signup | DB | Admin | Until deletion request |
| IP Address| Server | Logs | DevOps | 30 days |
| Name | Profile| DB | Admin | Until deletion request |
| Payment | Checkout| PCI vault| Finance| 7 years (tax) |
| Device ID | Analytics| DB | Analytics| 90 days |

This inventory becomes your reference point for implementing specific privacy controls. Share it with your entire team. developers, product managers, and legal counsel should all sign off on what is collected and why. If you cannot write a clear business justification for a data type, that is a strong signal you should not collect it.

This inventory becomes your reference point for implementing specific privacy controls

Conducting a Data Protection Impact Assessment

For higher-risk processing activities. large-scale profiling, systematic monitoring, or processing sensitive categories like health data. GDPR Article 35 requires a formal Data Protection Impact Assessment (DPIA). Even when not strictly mandatory, a DPIA is good practice. The assessment asks four core questions:

What is the nature and scope of the processing?
What is the purpose and necessity of the processing?
What risks does the processing create for individuals?
What measures can reduce or eliminate those risks?

Claude Code can assist here. Ask it to analyze your data model and flag processing activities that may require a DPIA, then document responses in structured markdown that your legal team can review and sign.

Skill Selection for Privacy-Conscious Development

Certain Claude skills directly support GDPR implementation. The pdf skill enables automated processing of data subject access requests by extracting relevant information from document repositories. The xlsx skill helps generate compliance reports and data export files required for user data portability requests.

For frontend implementations, the frontend-design skill incorporates accessibility considerations that intersect with privacy requirements. ensuring users can understand and control their data through properly labeled forms and clear consent mechanisms.

The tdd skill supports test-driven development of privacy features, allowing you to write acceptance tests for consent flows, data deletion routines, and access control before implementation begins.

GDPR Requirement	Relevant Article	Claude Skill
Consent management	Art. 7	tdd, frontend-design
Data portability	Art. 20	pdf, xlsx
Right to erasure	Art. 17	tdd
Data minimization	Art. 5(1)(c)	frontend-design
Breach notification	Art. 33	supermemory
Records of processing	Art. 30	xlsx

This mapping helps you prioritize which skills to install and configure early in a compliance-driven project.

Every piece of personal data collection requires a lawful basis. Consent is one of six lawful bases under Article 6, and for many consumer applications it is the primary one you will rely on. Build consent management into your initial architecture rather than retrofitting it later.

/tdd Create tests for consent state: user cannot be tracked before accepting cookies, consent state persists across sessions, user can withdraw consent at any time

This test-first approach ensures your consent system functions correctly from day one. Store consent records with timestamps and version numbers. if your privacy policy changes, you can demonstrate what users agreed to and when.

A minimal consent record should include:

CREATE TABLE consent_records (
 id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
 user_id UUID NOT NULL REFERENCES users(id),
 purpose VARCHAR(100) NOT NULL, -- 'analytics', 'marketing', 'functional'
 granted BOOLEAN NOT NULL,
 granted_at TIMESTAMPTZ,
 withdrawn_at TIMESTAMPTZ,
 policy_version VARCHAR(20) NOT NULL, -- tie consent to specific policy text
 ip_address INET,
 user_agent TEXT
);

Never overwrite consent records. Append new rows when consent is granted or withdrawn. the full audit trail is what protects you in a regulatory investigation. If a user grants analytics consent, withdraws it, then grants it again, you should have three rows, not one updated row.

Cookie banners that bundle all tracking into a single accept/reject are increasingly scrutinized by regulators. Implement granular consent by purpose:

const consentCategories = {
 necessary: true, // Always on, no choice required
 functional: false, // Session preferences, language
 analytics: false, // Usage tracking
 marketing: false // Personalization, retargeting
};

Give users a preference center they can return to at any time. Store the URL in your privacy policy so they can always revisit their choices.

Data Minimization: Collect Only What You Need

GDPR’s data minimization principle (Article 5(1)(c)) requires collecting only information that is adequate, relevant, and limited to what is necessary for your stated purpose. Review every field in your data collection forms against this standard.

Ask these questions for each data point:

Can we accomplish the task without this data?
Can we use pseudonyms or aggregated data instead?
Does this field serve the user or just ease our internal processes?
What is the worst-case outcome if this field is breached?

The frontend-design skill can help create forms that use progressive disclosure. showing optional fields only when relevant rather than presenting everything at once.

Practical Minimization Patterns

Use aggregation for analytics: Instead of storing “User Alice visited page /pricing at 14:32 on March 15”, store “50 users visited /pricing between 14:00-15:00 on March 15.” You get the insight without the personal data.

Pseudonymize identifiers in logs: Replace user IDs in application logs with one-way hashes. If you need to correlate a log entry back to a user for debugging, maintain a separate lookup table with strict access controls.

Apply field-level encryption for sensitive data: Payment card details, health information, and government ID numbers should be encrypted at the field level, not just at the database level. This limits exposure even if database credentials are compromised.

// Field-level encryption example using AES-256-GCM
const { createCipheriv, randomBytes } = require('crypto');
async function encryptField(plaintext, keyId) {
 const key = await kms.getKey(keyId);
 const iv = randomBytes(12);
 const cipher = createCipheriv('aes-256-gcm', key, iv);
 const encrypted = Buffer.concat([
 cipher.update(plaintext, 'utf8'),
 cipher.final()
 ]);
 return {
 ciphertext: encrypted.toString('base64'),
 iv: iv.toString('base64'),
 authTag: cipher.getAuthTag().toString('base64'),
 keyId
 };
}

Store the key ID alongside the ciphertext so you can rotate keys and re-encrypt data without breaking existing records.

Build Data Access and Deletion Capabilities

Users must be able to access their data and request deletion under Articles 15 and 17 respectively. These Data Subject Access Requests (DSARs) must be fulfilled within 30 days in most cases. Implementing the endpoints is the easy part. the hard part is knowing where all your data lives.

Complete DSAR Implementation

// Example: Data access endpoint
app.get('/api/user/data', authenticate, async (req, res) => {
 const userData = await db.users.findById(req.user.id);
 const userActivity = await db.activity.find({ userId: req.user.id });
 res.json({
 profile: userData,
 activity: userActivity,
 exports: await db.exports.find({ userId: req.user.id })
 });
});
// Example: Data deletion endpoint
app.delete('/api/user/data', authenticate, async (req, res) => {
 await db.users.softDelete(req.user.id);
 await db.activity.deleteMany({ userId: req.user.id });
 // Handle cascading deletions per your data model
});

The pdf skill can automate generating user data exports in standard formats, making portability requests straightforward to fulfill.

The Deletion Problem: Third-Party Data

Deleting data from your own database is straightforward. The harder question is what happens to data you have already shared with third parties. Your privacy policy and vendor contracts must address this. Each Data Processing Agreement (DPA) you sign should specify the vendor’s deletion obligations and timelines.

Maintain a list of every third-party service that receives user data:

Third-Party Data Processors
| Vendor | Data Sent | DPA Signed | Deletion SLA |
|-----------|------------------|------------|--------------|
| Stripe | Email, payment | Yes | 30 days |
| Mixpanel | User ID, events | Yes | 30 days |
| Intercom | Email, name | Yes | 30 days |
| SendGrid | Email | Yes | Immediate |

When a deletion request arrives, trigger deletion workflows with each vendor, not just your own database.

Secure Data Transmission and Storage

Implement encryption for data in transit (TLS) and at rest. Use environment variables for sensitive configuration:

Never commit these to version control
DATABASE_URL=postgresql://user:password@host/db
ENCRYPTION_KEY=your-256-bit-key

Claude Code can help you configure CI/CD pipeline checks for exposed secrets. Add a pre-commit hook that scans staged files for patterns like private keys or API tokens before they reach production.

TLS Configuration Hardening

Do not just enable TLS. configure it correctly. Outdated cipher suites and protocol versions are a common audit finding:

nginx TLS hardening example
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
add_header Strict-Transport-Security "max-age=63072000" always;

Use SSL Labs’ server test or a similar tool to verify your configuration scores an A or A+ before going to production.

Database Encryption at Rest

For PostgreSQL, enable pgcrypto for sensitive columns and consider Transparent Data Encryption at the infrastructure level. For AWS deployments, enable encryption at rest on RDS instances during creation. it cannot be added after the fact without a migration.

Document Your Compliance Journey

Maintain records demonstrating your privacy compliance efforts. This includes:

Data Processing Agreements with vendors
Privacy Impact Assessments for high-risk processing
Records of consent
Incident response procedures

Use version control to maintain an auditable history of privacy-related decisions. Each change to data handling should include a commit message explaining the privacy rationale.

Article 30 Records of Processing Activities

Article 30 requires organizations with 250 or more employees (and smaller organizations conducting certain types of processing) to maintain written records of processing activities. Even if not strictly required, maintaining this record is strongly recommended:

Records of Processing Activities
User Account Management
- Controller: Acme Corp, [email protected]
- Purpose: Provide user accounts and authentication
- Categories of data subjects: Registered users
- Categories of personal data: Name, email, hashed password
- Recipients: None (not shared externally)
- Transfers outside EEA: No
- Retention period: Until account deletion + 30 days
- Security measures: AES-256 encryption, TLS 1.3
Marketing Analytics
- Controller: Acme Corp, [email protected]
- Purpose: Understand product usage, improve features
- Categories of data subjects: Opted-in users
- Categories of personal data: Pseudonymized user ID, page views, events
- Recipients: Mixpanel (DPA in place)
- Transfers outside EEA: Yes. US (Mixpanel Privacy Shield successor framework)
- Retention period: 90 days
- Security measures: Pseudonymization, TLS 1.3

Regular Privacy Reviews

Schedule periodic reviews of your data handling:

Quarterly access logs review
Annual consent refresh campaigns
Regular vendor security assessments
Data retention policy enforcement

Automate retention enforcement where possible. delete user data automatically after the retention period expires rather than relying on manual processes.

Automating Retention with a Scheduled Job

// Retention enforcement job. run daily via cron
async function enforceRetention() {
 const cutoffDate = new Date();
 cutoffDate.setDate(cutoffDate.getDate() - 90); // 90-day retention for analytics
 const deleted = await db.activityLogs.deleteMany({
 createdAt: { $lt: cutoffDate }
 });
 console.log(`Retention job: deleted ${deleted.count} activity records older than ${cutoffDate.toISOString()}`);
 // Log to compliance audit table
 await db.complianceLog.insert({
 action: 'retention_enforcement',
 recordsDeleted: deleted.count,
 cutoffDate,
 executedAt: new Date()
 });
}

The compliance log entry matters as much as the deletion itself. When an auditor asks “can you prove you enforced your stated retention policy?”, this table provides the answer.

Breach Response Procedures

Article 33 requires notifying your supervisory authority within 72 hours of discovering a personal data breach. This timeline is extremely tight. Prepare your response procedure before you need it:

Detection. Define what constitutes a breach in your incident response policy
Containment. Isolate affected systems, revoke compromised credentials
Assessment. Determine scope, data types affected, number of individuals
Notification. Notify supervisory authority within 72 hours; notify affected individuals without undue delay if high risk
Remediation. Fix the vulnerability, implement additional controls
Documentation. Record the breach, even if no notification was required

Store your breach response runbook in a location accessible even if your primary systems are down. a printed copy in a physical binder is more reliable than a cloud document when you are in crisis mode.

Summary Checklist

Building privacy into your development process from the start costs less than retrofitting compliance later. Claude Code skills provide practical assistance, but the discipline of systematic privacy implementation comes from your development practices. Treat GDPR not as a legal checkbox but as a design constraint that produces better software. systems that collect less, store less, and expose less are inherently more resilient.

Try it: Paste your error into our Error Diagnostic for an instant fix.

I'm a solo developer in Vietnam. 50K Chrome extension users. $500K+ on Upwork. 5 Claude Max subscriptions running agent fleets in parallel. These are my actual CLAUDE.md templates, orchestration configs, and prompts. Not a course. Not theory. The files I copy into every project before I write a line of code. **[See what's inside →](https://zovo.one/lifetime?utm_source=ccg&utm_medium=cta-default&utm_campaign=claude-code-gdpr-data-privacy-implementation-checklist)** $99 once. Free forever. 47/500 founding spots left.