GDPR & Compliance

Security and compliance are related but different. Security protects data from attackers. Compliance ensures you're following laws and regulations that govern data handling. If you serve EU users, you need GDPR. If you handle health data, you need HIPAA. This guide covers key compliance frameworks and how developers implement them.

GDPR: General Data Protection Regulation

GDPR is the EU's data protection law. It applies if your app has users in the EU, regardless of where your company is located. Violating GDPR can result in fines up to 4% of global annual revenue (tens of millions for large companies).

What Counts as Personal Data

Personal data is any information about an individual—names, emails, IP addresses, cookies, user IDs, location data, phone numbers, photos. Anything identifying a person is personal data. Even pseudonymous data (user ID 12345) can be personal if you can link it to a person.

Lawful Basis for Processing

Before collecting data, you need a lawful basis. The main ones are:

Consent: The user explicitly agrees. The gold standard but requires clear, informed consent. Can't have pre-checked boxes or sneaky consent.

Contract: Processing is necessary for the contract with the user. If you're a SaaS, processing email is necessary for the service.

Legal obligation: You're required by law to process it.

Legitimate interests: You have a legitimate reason to process the data, and it's not overridden by the user's rights. This is vague and often contested.

Vital interests: Processing is necessary to protect someone's health or life.

You must document your lawful basis and be able to justify it. Don't just collect data because you might use it someday—you need a clear reason.

Privacy by Design

GDPR requires "privacy by design"—building privacy into your product from the start, not bolting it on later. Collect only what you need. Use data minimization—fewer data points, shorter retention, better privacy. Encrypt sensitive data. Audit access.

Consent Management and Cookie Banners

If you use cookies or analytics, you need consent before setting them (except for essential cookies required for the site to function). Implement a consent banner that clearly explains what data you collect and why.

Compliant consent banner:

- Clear opt-in (not pre-checked)

- Granular choices (users can consent to analytics but not marketing)

- Easy to reject (not buried in settings)

- Link to privacy policy

Right to Deletion (Right to be Forgotten)

Users can request deletion of their data. You must have a process to delete or anonymize all their personal data. This is technically complex—data might be in databases, backups, logs, caches.

Some data can't be deleted (tax records, legal holds), but most user data should be deletable. Implement a data deletion feature in your app that removes all personal data for a user. Test it to ensure it actually deletes everything.

Data Portability

Users can request their data in a portable format (JSON, CSV). This allows them to move their data to another service. Implement an export feature that provides all their personal data in a structured format.

Data Minimization

Only collect data you actually use. If you don't need phone numbers, don't ask for them. Don't keep data longer than necessary. After a user closes their account, delete their data after a retention period (maybe 30 days for logs, but not years).

This reduces privacy risk and is a core GDPR principle. Less data = less exposure if breached.

CCPA and California Privacy Laws

The California Consumer Privacy Act (CCPA) and newer California Privacy Rights Act (CPRA) apply if you serve California residents and process their data. Similar to GDPR, users have rights to know what data you have, delete it, and opt out of data sales.

CCPA is somewhat less strict than GDPR (broader definitions of when you can process data) but still requires privacy policies, opt-out mechanisms, and honoring deletion requests.

HIPAA: Health Data

HIPAA (Health Insurance Portability and Accountability Act) applies if you handle health data in the US. Requires encryption, access controls, audit logging, breach notification, and business associate agreements with third parties.

If you build a health app or process medical records, HIPAA applies. It's strict—substantial fines for violations. Engage a compliance specialist for HIPAA applications.

SOC 2 Compliance

SOC 2 (Service Organization Control 2) is a certification showing you have controls for security, availability, and confidentiality. Many enterprise customers require SOC 2 compliance from their vendors.

Achieving SOC 2 requires:

- Access controls (who can access what)

- Encryption (data at rest and in transit)

- Audit logging (who did what)

- Incident response (what you do when security events happen)

- Penetration testing (verifying security)

An auditor reviews your systems and processes, issuing a report. This report doesn't mean you're hacker-proof—it means you have reasonable controls. It's valuable for sales to enterprise customers but isn't legally required.

Other Compliance Frameworks

PCI-DSS: Required if you handle credit card payments. Requires encryption, access controls, and regular security testing.

FERPA: Education data in the US. If you build a student information system, FERPA applies.

FTC Act: US law that applies to data security. The FTC can fine companies for misleading data practices.

Australian Privacy Act: If you serve Australian users, similar requirements to GDPR but less strict.

Building Compliance Into Your App

Privacy Policy

Write a clear privacy policy explaining what data you collect, why, how you use it, how long you keep it, and what rights users have. The policy must be accurate and specific—don't just copy a template.

Data Deletion and Export Features

Build these into your app. Users should be able to request their data or delete their account from your settings. This isn't just compliant—it's good UX.

Consent Management

For cookies or analytics, implement a consent banner. Track consent and respect user preferences. If users opt out of analytics, don't track them.

Audit Logging

Log access to sensitive data. Who accessed what, when, and why? This is required for HIPAA, SOC 2, and helpful for GDPR breach notifications.

Data Retention Policies

Define how long you keep data. After 90 days of inactivity, automatically delete logs. After a user closes their account, delete their data after 30 days. Fewer data = less risk.

When to Engage a Compliance Specialist

For small teams building simple apps, you might handle compliance yourself. But engage a specialist for:

- HIPAA applications (health data)

- SOC 2 audits (before enterprise sales)

- Large-scale data collection (complex GDPR implications)

- Multi-jurisdiction apps (different laws in different regions)

- Financial services or payment processing

A lawyer specializing in data privacy can review your policies and practices, ensuring compliance and reducing legal risk.

Compliance and Security Are Partners

Compliance isn't opposed to security—it reinforces it. GDPR requires encryption and access controls (security). SOC 2 requires audit logging and incident response (security). HIPAA requires penetration testing (security). Regulations push you toward better security practices.

The best approach: build security and privacy into your product from day one. Encrypt data, minimize collection, implement access controls, and audit activity. Then, mapping to compliance frameworks is mostly documentation—proving you already do the right things.

Start simple. Understand what regulations apply to your app (based on user location and data type). Implement the basics (encryption, access controls, privacy policy). As you grow and handle more sensitive data, invest in compliance specialists. Privacy and security are not burdens—they're fundamental to building trust with your users.