The General Data Protection Regulation is not a checkbox exercise — it is a fundamental shift in how software is architected, built, and operated. Enforcement data shows regulators are increasingly targeting technology companies, and the average fine per major violation has grown year-over-year since 2018.
Whether you are building a consumer mobile app, a B2B SaaS platform, or an internal enterprise tool, if any user resides in the European Economic Area (EEA), GDPR applies to you — regardless of where your company is registered. That includes companies in Canada, the USA, India, and Australia.
At Codazz, we integrate GDPR requirements into our architecture and sprint planning from day one — not as an afterthought before launch.
GDPR Basics: Who It Applies to & Key Principles
GDPR entered into force on 25 May 2018 and replaced the 1995 Data Protection Directive. It applies in two scenarios: you are established in the EU/EEA, or you offer goods/services to, or monitor the behaviour of, EU/EEA residents. The second criterion — known as the extraterritorial scope under Article 3(2) — is what catches most global startups off guard.
The 7 GDPR Principles (Article 5)
Lawfulness, Fairness & Transparency
Processing must have a legal basis; users must know what you do with their data.
Purpose Limitation
Collect data for specific, explicit, legitimate purposes. Do not reuse it for incompatible purposes.
Data Minimisation
Collect only what is adequate, relevant, and limited to what is necessary.
Accuracy
Keep personal data accurate and up to date; erase or correct inaccurate data without delay.
Storage Limitation
Keep data in identifiable form only as long as necessary for its purpose.
Integrity & Confidentiality
Appropriate security against unauthorised access, accidental loss, destruction, or damage.
Accountability
The controller is responsible for and must be able to demonstrate compliance.
Territorial scope trap: If your React app uses Google Analytics without consent for a visitor from Germany, you are processing personal data of an EU resident without a legal basis — a GDPR violation — even if your servers are in Canada.
8 Data Subject Rights & How to Implement Them
GDPR grants individuals eight enforceable rights over their personal data. You must be able to respond to requests within 30 days (extendable to 3 months for complex requests). Here is what each right means technically and how to implement it:
Right of Access (Article 15)
What it means: Users can request a copy of all personal data you hold about them and information about how it is processed.
How to implement: Build a “Download My Data” feature that exports all user records across your database tables, logs, and third-party integrations into a structured JSON or CSV file. Maintain a data map so you know where every field lives.
Right to Erasure / Right to be Forgotten (Article 17)
What it means: Users can request deletion of their data when it is no longer necessary, consent is withdrawn, or they object to processing.
How to implement: Implement a soft-delete system first (flag as deleted, stop processing), then a hard-delete job that runs on a schedule. Document any data you are legally required to retain (e.g., invoices for 7 years) and explain this in your privacy policy. Propagate deletion requests to all sub-processors within 30 days.
Right to Rectification (Article 16)
What it means: Users can correct inaccurate personal data held about them.
How to implement: Provide an in-app profile editor for self-service corrections. For data users cannot edit themselves (e.g., transaction records), provide a support flow with identity verification. Log all corrections with timestamps.
Right to Data Portability (Article 20)
What it means: Users can receive their data in a machine-readable format and transfer it to another service.
How to implement: Export data as JSON, CSV, or XML — not proprietary formats. Your API should include a /users/me/export endpoint. For health or financial apps, consider FHIR or OFX formats for interoperability.
Right to Object (Article 21)
What it means: Users can object to processing for direct marketing, profiling, or legitimate interest purposes.
How to implement: Include opt-out controls in notification settings and marketing preferences. When a user opts out of marketing, immediately suppress them in your email platform (Mailchimp, SendGrid) and ad platforms. Legitimate interest objections must be honoured unless you can demonstrate compelling grounds.
Right to Restrict Processing (Article 18)
What it means: Users can request that processing is paused — data is retained but not actively used — while a dispute is resolved.
How to implement: Implement a processing_restricted boolean flag at the user level. Your application logic must check this flag before any processing operations (analytics, profiling, personalisation). Consider a separate restricted_users table for clarity.
Rights Related to Automated Decision-Making (Article 22)
What it means: Users have the right not to be subject to decisions made solely by automated processing that significantly affect them (e.g., credit decisions, hiring algorithms).
How to implement: If you use ML models for consequential decisions, document the logic, provide a human review process, and inform users that automated processing is taking place. Never use fully automated processing for high-stakes decisions without human oversight.
Right to Withdraw Consent (Article 7(3))
What it means: Withdrawing consent must be as easy as giving it, and withdrawal must not retroactively affect the lawfulness of prior processing.
How to implement: Your consent UX must have a clearly visible withdrawal mechanism on the same screen or within one click of where consent was granted. Update your consent records database immediately on withdrawal and stop all consent-dependent processing.
Legal Bases for Processing Personal Data
Every single act of processing personal data must rest on one of six legal bases defined in Article 6. Choosing the wrong one is a common compliance mistake — particularly relying on consent when legitimate interest or contract would be more appropriate (and more stable legally).
Consent
Art. 6(1)(a)Flexible but fragile
When to use: Marketing emails, optional cookies, newsletters, personalised ads.
Must be freely given, specific, informed, and unambiguous. Silence or pre-ticked boxes do not count. Can be withdrawn at any time.
Contract
Art. 6(1)(b)Strong for core features
When to use: Processing payment details, shipping addresses, account credentials — any data necessary to deliver your service.
Only covers data strictly necessary for the contract. You cannot use “contract” as a basis for marketing or analytics.
Legal Obligation
Art. 6(1)(c)Mandatory retention
When to use: Tax records, KYC for fintech, mandatory fraud reporting, employment records.
The law requires you to keep this data. Users cannot request erasure for data held under legal obligation.
Vital Interests
Art. 6(1)(d)Emergency use only
When to use: Sharing location data with emergency services, disclosing health data in a life-threatening situation.
Only a last resort when the data subject is incapable of giving consent and another basis is unavailable.
Public Task
Art. 6(1)(e)Government/research
When to use: Public sector bodies, official authorities, research institutions exercising official functions.
Rarely applies to private companies unless carrying out a task clearly in the public interest.
Legitimate Interest
Art. 6(1)(f)Powerful but tested
When to use: Fraud prevention, network security, direct marketing to existing customers, improving your own service.
Requires a Legitimate Interest Assessment (LIA) — a three-part test balancing your interest against the individual's rights. Cannot override consent where consent is required.
Common mistake: Using “consent” as a legal basis for all processing. If a user withdraws consent, you must stop all processing dependent on it — including analytics and session tracking. For core app functionality, “contract” is a more stable legal basis.
Cookie Consent: Implementation, Banner Design & IAB TCF
Cookie consent is governed by GDPR (for personal data) and the ePrivacy Directive (for accessing/storing data on a device). Non-essential cookies — analytics, advertising, personalisation — require explicit opt-in consent before being set. Here is how to implement it correctly.
Cookie Categories
Strictly Necessary
No consent required
Session cookies, CSRF tokens, load balancer cookies, user authentication
Functional / Preferences
Consent required
Language preferences, region settings, saved form data, chat widgets
Analytics / Performance
Consent required
Google Analytics, Mixpanel, Hotjar, Segment, PostHog
Marketing / Advertising
Consent required
Facebook Pixel, Google Ads, LinkedIn Insight, retargeting pixels
Consent Banner Design Requirements
Regulators have issued guidance on what constitutes valid consent through a cookie banner. Misleading dark patterns — like hiding the “Reject All” button or making acceptance easier than rejection — have been fined extensively (French CNIL fined Google €150M and Facebook €60M in 2022 for exactly this).
| Requirement | Valid | Invalid (Dark Pattern) |
|---|---|---|
| Accept / Reject buttons | "Accept All" and "Reject All" at same prominence | "Accept All" button, reject buried in settings link |
| Pre-selection | All non-essential cookies unchecked by default | Analytics cookies pre-ticked |
| Colour/contrast | Both buttons same style and colour | Accept in green, reject greyed out |
| Withdrawal | Persistent "Manage Cookies" link in footer | No way to change preferences after initial choice |
| Information | Plain-language description of each cookie category | Vague "improve your experience" language only |
| Granularity | Separate toggles per cookie category | Single accept-all only option |
IAB Transparency & Consent Framework (TCF 2.2)
The IAB Europe TCF is a standardised protocol that enables publishers, CMPs, and ad tech vendors to communicate consent signals in programmatic advertising. If your app monetises via programmatic ads, you need TCF compliance on top of basic GDPR consent.
- Register with an IAB-registered CMP (Didomi, Usercentrics, OneTrust)
- The CMP generates a TC String encoding each vendor's consent/legitimate interest status
- The TC String is stored in a first-party cookie (
euconsent-v2) and shared via the__tcfapiJavaScript API - SSPs and DSPs read this string before serving ads — no valid consent means no personalised ads
- TCF 2.2 (2023) increased restrictions on legitimate interest for advertising — consent is now required for most ad targeting purposes
Privacy by Design: Data Minimisation & Pseudonymisation
Article 25 of GDPR mandates “Data Protection by Design and by Default” — privacy controls must be built into your system architecture from the start, not retrofitted. Here is what this means at the database and application layer:
Data Minimisation in Schema Design
Before adding a field to your database schema, ask: “Do we actually need this, and for what specific purpose?” Common over-collection examples include storing full date-of-birth when you only need age verification, storing device fingerprints for analytics when session IDs suffice, or collecting phone numbers “just in case”.
-- Over-collection (avoid)
CREATE TABLE users ( id UUID PRIMARY KEY, email TEXT NOT NULL, full_name TEXT, date_of_birth DATE, -- Only needed if age-gating phone TEXT, -- Needed? For what purpose? ip_address INET, -- Log separately, delete sooner device_id TEXT -- Requires consent for tracking );
-- Minimised (preferred)
CREATE TABLE users ( id UUID PRIMARY KEY, email_hash TEXT NOT NULL, -- Hashed for pseudonymisation display_name TEXT, -- Not necessarily real name is_adult BOOLEAN, -- Boolean instead of DOB created_at TIMESTAMPTZ, retention_expires_at TIMESTAMPTZ );
Pseudonymisation Techniques
Pseudonymisation replaces directly identifying information with artificial identifiers, reducing the risk associated with a data breach. GDPR explicitly encourages pseudonymisation as a technical safeguard (Recital 28). Unlike anonymisation, pseudonymous data can still be re-identified with additional information — so it remains personal data, but attracts reduced regulatory scrutiny.
Tokenisation
Replace sensitive values (email, SSN) with opaque tokens. Store the mapping in a separate, access-controlled vault (e.g., HashiCorp Vault or AWS KMS). Analytics systems only see the token.
Hashing with Salt
SHA-256 or bcrypt with a per-user salt. Useful for email lookups without storing plaintext emails. Cannot be reversed without the original value.
Data Masking
Replace characters in sensitive fields (john@example.com → j***@e******.com). Used in logs, support interfaces, and non-production environments.
Synthetic Data
Replace real user data in dev/staging environments with statistically similar synthetic records. Tools: Faker.js, Gretel.ai, Presidio. Never use real production data in dev.
Data Retention Policies & Auto-Deletion
GDPR's Storage Limitation principle requires you to define how long you keep each category of data — and to enforce those limits automatically. “We keep data indefinitely” is not a valid retention policy.
| Data Category | Suggested Retention | Legal Basis / Notes |
|---|---|---|
| Account / profile data | Duration of account + 30 days after deletion request | Contract; extend if legal hold required |
| Transaction / invoice records | 7 years | Legal obligation (tax/accounting laws) |
| Server access logs (IP addresses) | 90 days | Legitimate interest (security); minimise after |
| Error logs | 30 days | Legitimate interest; scrub personal data after 7 days |
| Marketing consent records | 3 years after last interaction | Consent; must prove consent was given |
| GDPR request records (DSARs) | 3 years | Legal obligation; evidence of compliance |
| Analytics / behavioural data | 13 months (GA4 default) | Consent; anonymise after retention period |
| Cookies (consent records) | 13 months max | ePrivacy Directive; re-ask after expiry |
| Job application data (rejected) | 6 months | Legitimate interest; candidate informed |
| Support ticket data | 2 years after resolution | Legitimate interest; scrub sensitive content after 6 months |
Implementing Auto-Deletion
-- Add retention column to each table
ALTER TABLE audit_logs ADD COLUMN expires_at TIMESTAMPTZ GENERATED ALWAYS AS (created_at + INTERVAL '90 days') STORED;
-- Nightly deletion job (run via pg_cron)
SELECT cron.schedule('purge-expired-logs', '0 2 * * *', $$ DELETE FROM audit_logs WHERE expires_at < NOW(); $$);
DPA Agreements with Vendors (AWS, Firebase, Mixpanel & More)
Under Article 28, any vendor you share personal data with is a data processor, and you must have a Data Processing Agreement (DPA) in place before sharing data. This is non-negotiable. Using a SaaS tool without a DPA is a GDPR violation, even if the vendor is GDPR-compliant themselves.
AWS
DPA AvailableHow: Accept AWS GDPR DPA via the AWS console under Account > Data Privacy. AWS acts as a processor for data stored in your AWS services.
Note: Enables Standard Contractual Clauses (SCCs) for data transfers outside EEA.
Google Firebase / GCP
DPA AvailableHow: Sign the Google Cloud Data Processing Addendum at myaccount.google.com. Covers Firebase, BigQuery, Cloud Storage, and other GCP services.
Note: Firebase Analytics sends data to Google servers — requires consent if used for behavioural tracking.
Mixpanel
DPA AvailableHow: Request and sign Mixpanel's DPA via their privacy portal. Configure data residency to EU. Enable IP anonymisation.
Note: Mixpanel ingests user IDs, events, and properties — all personal data requiring consent.
Stripe
DPA AvailableHow: Stripe's DPA is incorporated into their Services Agreement — automatically accepted when you agree to their ToS.
Note: Stripe also processes data as a controller (fraud detection, Stripe Radar) — two separate legal relationships.
Mailchimp / Intuit
DPA AvailableHow: Download and execute Mailchimp's DPA. Standard Contractual Clauses are required for EEA → US transfers.
Note: Only send marketing emails to users who have given explicit consent.
Intercom
DPA AvailableHow: Enable GDPR controls in Intercom settings. Set data retention periods. DPA is included in their subscription agreement.
Note: Intercom chat widgets load JS on page load — requires consent before initialisation if using identity resolution.
Sentry
DPA AvailableHow: Request Sentry's DPA via their privacy team. Configure data scrubbing to remove PII from error reports before they leave your server.
Note: Sentry can capture PII in stack traces and request headers — configure beforeSend hooks to strip sensitive data.
HubSpot
DPA AvailableHow: HubSpot's DPA is part of their MSA. Enable GDPR features in Settings > Privacy & Consent. Use built-in consent workflows.
Note: HubSpot cookie tracks visitors before consent — use cookie blocking mode and initialise tracking only after consent.
Processor Register: Maintain a Record of Processing Activities (ROPA) under Article 30. This is a living spreadsheet listing every data category, its purpose, legal basis, retention period, processor, and transfer mechanism. It is the first thing a regulator will request during an audit.
Breach Notification: The 72-Hour Rule
Article 33 requires you to notify your lead supervisory authority within 72 hours of becoming aware of a personal data breach — not 72 hours after the breach, but after you become aware. Late notifications have resulted in significant additional fines on top of the breach-related penalties.
What Constitutes a Breach?
A personal data breach is any event leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. This includes:
Database server publicly exposed without authentication
Employee laptop with unencrypted user data stolen
S3 bucket misconfiguration exposing customer records
SQL injection attack resulting in data exfiltration
Email sent to wrong recipient containing PII
Ransomware encrypting and threatening to publish data
Third-party vendor breach that included your users' data
Accidental deletion of data without backup (availability breach)
Breach Response Runbook
0 min
Detect & Contain
Isolate affected systems. Revoke compromised credentials. Preserve evidence — do not wipe logs.
1–4 hrs
Assess Severity
Determine: what data was breached, how many individuals affected, whether special categories (health, financial) are involved, and whether harm is likely.
4–24 hrs
Internal Escalation
Notify DPO, legal team, and senior management. Start breach documentation. Determine notification obligations.
24–72 hrs
Supervisory Authority Notification
Notify your lead supervisory authority (e.g., ICO in UK, CNIL in France, DPC in Ireland). Provide: nature of breach, categories and number of individuals, approximate number of records, likely consequences, measures taken.
ASAP if high risk
Notify Affected Individuals
Article 34: if breach is likely to result in high risk to individuals (identity theft, discrimination, financial loss), notify affected users directly — in plain language, without undue delay.
Ongoing
Document & Review
Maintain a breach register under Article 33(5). Conduct post-mortem. Update controls. Consider notifying cyber insurance carrier.
Mobile-Specific GDPR: Permissions, Analytics & Advertising ID
Mobile apps have unique GDPR considerations beyond web applications. The combination of persistent device identifiers, background location tracking, and OS-level permission systems creates specific compliance challenges.
App Permissions & Purpose Limitation
- Only request permissions you actively use — not “just in case”
- Request at time of use (contextual), not at app launch
- On Android 13+: granular photo/media permissions
- On iOS: provide usage description strings for every sensitive permission
- Do not request microphone permission for a notes app
- Contacts access requires clear consent and minimised usage
Advertising ID (IDFA/GAID)
- iOS: Apple's ATT framework requires explicit permission before accessing IDFA (since iOS 14.5)
- Android: Google Advertising ID requires opt-out support
- If user opts out: do not fingerprint as a workaround — this violates GDPR and platform policies
- Use aggregated cohort attribution (SKAdNetwork on iOS, Privacy Sandbox on Android) for ad measurement without individual tracking
Analytics SDK Opt-Out
- Firebase Analytics: call setAnalyticsCollectionEnabled(false) until consent granted
- Mixpanel: call optOutTracking() method on opt-out
- Amplitude: use setOptOut(true) on the Amplitude instance
- Provide in-app privacy settings where users can toggle analytics on/off
- Store consent state in encrypted local storage, not in analytics platforms themselves
Push Notifications & Consent
- iOS: push permission is a system dialog — no separate GDPR consent needed for the permission itself
- Marketing push notifications still require GDPR consent as a legal basis
- Transactional notifications (order confirmations) can rely on contract legal basis
- Provide granular notification preferences: marketing, product updates, reminders
- Honour unsubscribe immediately — sync with your backend within seconds
CCPA vs GDPR: Key Differences
If your app serves users in both the EU and California, you must comply with both GDPR and the California Consumer Privacy Act (CCPA), as amended by CPRA. While they share privacy principles, they differ significantly in scope, opt-in vs opt-out approach, and enforcement.
| Dimension | GDPR (EU/EEA) | CCPA/CPRA (California) |
|---|---|---|
| Scope | Any business processing EU resident data, regardless of size | Businesses in CA with >$25M revenue, >100K consumers' data/yr, or >50% revenue from selling data |
| Consent model | Opt-in required for non-essential processing | Opt-out (do not sell/share) for most processing; opt-in for minors under 16 |
| Cookies | Opt-in consent required before setting non-essential cookies | Opt-out of cookie-based tracking; GPC signal must be honoured |
| Right to erasure | Broad right with limited exceptions | Right to delete; more exceptions (free speech, security, legal obligations) |
| Data portability | Machine-readable format required | Two specific portable disclosures per year |
| Sensitive data | Special categories require explicit consent (health, race, religion, biometrics) | Sensitive PI requires opt-in consent (similar categories plus precise geolocation) |
| Private right of action | No (regulatory enforcement only) | Yes — for data breaches: $100–750 per consumer per incident |
| Max fines | €20M or 4% of global annual turnover | $7,500 per intentional violation; $2,500 per unintentional |
| DPO required | Yes, for certain organisations (large-scale processing, special categories) | No formal DPO requirement |
| DPIA/PIA required | Yes for high-risk processing | Voluntary; CPRA introduced risk assessments for high-risk activities |
| Territorial scope | Global (any business with EU users) | Businesses serving California residents (extraterritorial effect) |
| Enforcement body | National supervisory authorities (ICO, CNIL, DPC, etc.) | California Privacy Protection Agency (CPPA), California AG |
Practical tip: Design for GDPR compliance first — it is more stringent. A GDPR-compliant opt-in consent system will generally satisfy CCPA opt-out requirements as well. The reverse is not true: a CCPA-only system (opt-out model) will not satisfy GDPR's opt-in requirement.
Consent Management Platforms (CMPs)
Building a consent management system from scratch is error-prone and expensive to maintain as regulations evolve. A CMP handles consent collection, storage, signal transmission to vendors (via IAB TCF), and provides a compliance audit trail. Here are the leading options in 2026:
OneTrust
$$$Pros
- Most comprehensive feature set
- DPIA/PIA workflow tools
- Vendor risk management
- Geolocation-based consent rules
- SOC 2 + ISO 27001 certified
Cons
- Complex implementation (4–8 weeks)
- Expensive ($2K–$15K/month)
- Can slow page load if misconfigured
Best for: Large enterprises with compliance teams and complex multi-jurisdiction requirements
Cookiebot (Usercentrics)
$$Pros
- Automatic cookie scanning
- Easy 2-day implementation
- IAB TCF certified
- Google Consent Mode v2 support
- CCPA + GDPR + LGPD
Cons
- Less customisable than OneTrust
- Cookie scan not always 100% accurate
- Limited workflow automation
Best for: SaaS companies and e-commerce wanting quick GDPR compliance without a dedicated compliance team
Didomi
$$Pros
- Strong IAB TCF 2.2 implementation
- Headless consent API for mobile apps
- React Native SDK available
- Privacy UX templates
- Real-time consent reporting
Cons
- Less brand recognition than OneTrust
- Vendor list management requires effort
Best for: Companies with both web and mobile apps needing unified consent infrastructure
Osano
$Pros
- Simple pricing model
- Built-in vendor monitoring
- Consent change alerts
- Easy WordPress/Shopify integration
- Good data subject request workflow
Cons
- Less advanced IAB TCF features
- Fewer global regulation templates
Best for: Small businesses and startups getting started with GDPR compliance on a budget
Consent-O-Matic (Open Source)
FreePros
- No vendor dependency
- Full control over implementation
- Lightweight
- No monthly fees
Cons
- Requires developer maintenance
- No automatic vendor updates
- No IAB TCF support out of the box
- No compliance audit trail
Best for: Simple apps with few third-party vendors and developer resources for ongoing maintenance
Notable GDPR Fines: What They Tell Us
GDPR enforcement has escalated dramatically. Cumulative fines issued by European supervisory authorities exceeded €4.5 billion by the end of 2025. Here are the most instructive cases — and what they mean for your architecture decisions:
Meta (Facebook)
Irish DPC · 2023
€1.2 Billion
fine issued
Violation: Unlawful data transfers from EU to US — using Standard Contractual Clauses (SCCs) while knowing that US surveillance law (FISA 702) made meaningful protection impossible.
Lesson for developers: Data transfers to the US after Schrems II require a Transfer Impact Assessment (TIA). The EU-US Data Privacy Framework (2023) provides a new transfer mechanism — verify your vendors are certified or rely on updated SCCs with a robust TIA.
Amazon
Luxembourg CNPD · 2021
€746 Million
fine issued
Violation: Non-compliant cookie consent — advertising cookies were set without valid consent. Amazon used dark patterns to make opting out difficult.
Lesson for developers: Cookie consent UX is under active regulatory scrutiny. The “Accept All” button cannot be more prominent than “Reject All.” This is pure front-end compliance — no engineering complexity, just UX discipline.
Instagram (Meta)
Irish DPC · 2022
€405 Million
fine issued
Violation: Processing children's data (minors 13–17) — phone numbers and email addresses were set to public by default on business accounts.
Lesson for developers: Privacy-by-default means the most private settings are active by default, especially for vulnerable groups. Age verification and parental consent for under-16s require dedicated engineering investment.
TikTok
Irish DPC · 2023
€345 Million
fine issued
Violation: Children's data privacy violations — public-by-default settings for minors, dark patterns in consent flows, and failure to verify user ages adequately.
Lesson for developers: If your app may be used by under-16s, age verification is not optional. Dark patterns in consent — nudge language, hidden reject options — are now being fined directly.
WhatsApp (Meta)
Irish DPC · 2021
€225 Million
fine issued
Violation: Transparency failures — insufficient information to users about how their data was shared between WhatsApp and the broader Meta family of companies.
Lesson for developers: Privacy notices must be specific about data sharing between affiliated companies. “We may share data with affiliates” is insufficient — each sharing relationship needs a specific description and legal basis.
Google + Facebook (France)
French CNIL · 2022
€150M + €60M
fine issued
Violation: Cookie consent UX — rejecting cookies required more clicks than accepting, and the reject mechanism was insufficiently prominent.
Lesson for developers: Regulatory precedent: “Reject All” must require the same number of clicks as “Accept All.” This is now the de-facto standard in EU cookie compliance.
Frequently Asked Questions
Need Help Building a GDPR-Compliant App?
Codazz builds privacy-by-design into every project — from data schema design to consent management platform integration, DPA agreements, and breach response runbooks. We have helped fintech, healthcare, and SaaS companies launch compliantly in the EU and globally.
Get a GDPR Compliance Review