GDPR and CCPA for Custom Software: What Developers Must Build In

Last updated: September 3, 2026 · By Joseph Olivas, Founder, MEAN Consultors · 10 min read

Most of the U.S. business owners I work with assume privacy law is someone else’s problem: a European issue, or a big-tech issue. Then they land a customer in Germany, or their user count in California crosses a threshold, and the software they commissioned two years ago has no way to export a person’s data or delete it cleanly. At that point compliance becomes a rewrite. This article is about avoiding that outcome by treating GDPR and CCPA as software requirements from day one, which is how we approach it at MEAN Consultors.

A necessary caveat: I am a software consultant, not an attorney. What follows is an engineering translation of the two laws, meant to help you brief a developer and ask better questions of your counsel.

Does either law apply to your software?

The General Data Protection Regulation (GDPR) applies to any organization, anywhere, that processes personal data of people in the European Union or European Economic Area in connection with offering them goods or services or monitoring their behavior. There is no revenue floor. If your application knowingly serves EU residents, it applies.

The California Consumer Privacy Act (CCPA), as amended by the California Privacy Rights Act (CPRA), applies to for-profit businesses that do business in California and meet any one of three thresholds: annual gross revenue above a figure that started at $25 million and is adjusted for inflation (about $26.6 million for 2025), buying, selling, or sharing the personal information of 100,000 or more California consumers or households, or deriving 50% or more of revenue from selling or sharing personal information. Smaller companies are often outside CCPA today but inside it after a growth year, which is a strong argument for building the capabilities before you need them.

Penalties are real in both regimes. GDPR fines can reach €20 million or 4% of worldwide annual turnover, whichever is higher, for the most serious violations. CCPA administrative fines run up to $2,500 per violation and $7,500 per intentional violation or violation involving minors (also inflation-adjusted), and “per violation” can mean per affected consumer. The indirect costs are larger: IBM’s 2025 Cost of a Data Breach report put the global average breach at $4.44 million and the U.S. average at $10.22 million.

The two laws side by side, for engineers

Lawyers compare these laws by legal theory. Developers need to compare them by what the software has to do. Here is the mapping we use in scoping.

The statutory clocks your software has to keep

Several requirements are deadlines, and deadlines are a workflow problem. Under GDPR, you have one month to respond to an access or erasure request, extendable by two further months for complex cases, and 72 hours from becoming aware of a breach to notify the supervisory authority. Under CCPA, you have 45 days to respond to a consumer request, extendable once by another 45. California’s breach statute does not set a fixed number of hours, but requires notification in the most expedient time possible and without unreasonable delay.

Figure 1: GDPR’s 72-hour breach clock is the tightest deadline in either law and dictates your monitoring design.

The engineering consequence is that request handling cannot live in an inbox. Build or buy a request-tracking queue that timestamps receipt, verifies identity, assigns an owner, and escalates as the clock runs. For breaches, the 72-hour window means detection has to be automated; a quarterly log review does not qualify as “awareness” in any useful sense.

Privacy by design: where each requirement lives in the code

GDPR Article 25 makes “data protection by design and by default” an explicit obligation. In practice that means the requirements above are distributed across every layer of an application, which is why they are so expensive to add late.

Figure 2: Each requirement has a home in a specific layer; erasure and retention live in the data layer and are hardest to retrofit.

A few of these deserve specific engineering notes.

The personal-data inventory. Before any other feature, catalog every field that identifies or relates to a person: name, email, IP address, device ID, location, and anything derived from them. Tag each with its purpose, lawful basis, retention period, and every downstream system it flows to. This inventory drives export, deletion, and breach scoping; without it you are guessing in all three.

Cascading erasure. Deletion has to reach primary tables, search indexes, caches, analytics events, message queues, exported reports, and vendors. Where a hard delete would break referential integrity or financial records, anonymize instead: replace identifiers with irreversible tokens and keep the transaction. Decide the backup policy up front; most teams choose to let backups age out on a fixed schedule and document that, rather than editing backups.

Consent records. Store consent as an event, not a boolean: who, when, which version of the notice, through which interface, and the withdrawal event if it happens. Under CCPA, also store whether a Global Privacy Control signal was received and honored.

Encryption and logging. Encrypt personal data at rest and in transit, pseudonymize where analysis does not need identities, and keep an append-only log of who accessed or changed personal data. I covered the practical side in data encryption basics for business owners; the compliance point is that Article 32 and California’s “reasonable security” standard are judged after a breach, and encryption is the control most likely to reduce both the fine and the notification burden.

Vendors, processors, and the software you did not write

Your application almost certainly sends personal data to third parties: email providers, analytics, payment processors, cloud hosting, AI APIs. Under GDPR these are processors and require a data processing agreement; under CCPA they are service providers or contractors and require specific contract terms, including an obligation to delete on instruction. From an engineering standpoint, every integration in your inventory needs a corresponding contract, a documented data flow, and a deletion hook. This is one of the reasons we insist on vetting a software development partner on data handling before the first line of code, and why data privacy when using AI tools deserves its own review.

The build-in checklist

When we scope privacy-regulated software, these items go into the requirements document alongside the business features, not as a compliance appendix.

• Personal-data inventory maintained as code or configuration, with purpose, basis, retention, and downstream flows per field.
• Consent and preference center supporting opt-in (GDPR) and opt-out (CCPA) models, versioned notices, and Global Privacy Control detection.
• Self-service access request that exports every record tied to a verified identity in a common machine-readable format.
• Erasure routine that cascades to all stores and vendors, with anonymization where deletion is legally or technically inappropriate.
• Retention schedule per field with automated purge jobs and a log of what was purged when.
• Encryption at rest and in transit, role-based access, and an append-only audit log for personal-data access and changes.
• Request-tracking queue with statutory clocks, identity verification, and escalation.
• Breach detection alerting plus a written, rehearsed notification workflow that can produce a regulator notice within 72 hours.
• Data processing agreements and deletion hooks for every third-party integration.
• Annual privacy review tied to the software roadmap, so new features inherit the controls.

Why building it in costs less than adding it later

The economics are simple even without precise numbers. Each capability above touches the data model. Adding a purpose tag or a retention field to a schema during design is a line in a migration; adding it to a production system with three years of data, a dozen integrations, and reports that depend on the current shape is a project. Erasure is the extreme case: designed in, it is a routine that walks a known graph of records; retrofitted, it is an archaeology exercise.

That is the argument for treating privacy as part of the secure software development lifecycle rather than a launch-week checklist. The same discipline that hardens API security and threat-models a new feature can carry the privacy requirements along with it, at a fraction of the cost of a later remediation. If your current system cannot answer “show me everything we hold on this person and delete it,” that is the first thing to fix.

Frequently Asked Questions

Does GDPR apply to a small U.S. business with no European office?

Yes, if the business offers goods or services to people in the EU or EEA or monitors their behavior. GDPR has no revenue or size threshold. A U.S. software product that knowingly serves EU users is within scope.

What are the CCPA thresholds for a business in 2025?

A for-profit business doing business in California is covered if it exceeds roughly $26.6 million in annual gross revenue (the original $25 million figure, inflation-adjusted), buys, sells, or shares personal information of 100,000 or more California consumers or households, or earns 50% or more of revenue from selling or sharing personal information.

What does “privacy by design” mean for custom software?

It is the GDPR Article 25 obligation to build data protection into systems from the start rather than adding it later. In practice this means a personal-data inventory, purpose-limited fields, consent records, self-service access and deletion, retention automation, encryption, and audit logging designed into the data model and workflows.

How fast must a company respond to a data access or deletion request?

Under GDPR, within one month, extendable by two further months for complex requests. Under CCPA, within 45 days, extendable once by an additional 45 days. Both clocks start at receipt, so request intake must be timestamped and tracked.

What is the GDPR breach notification deadline?

Controllers must notify the relevant supervisory authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to individuals. Meeting this requires automated detection and a rehearsed notification workflow.

Do GDPR and CCPA require the same software features?

Largely yes. Data inventory, access and export, deletion, correction, retention limits, security controls, and breach response are shared. The main difference is consent: GDPR generally requires opt-in consent while CCPA relies on opt-out rights, so a preference center must support both models.

Is deleting data from backups required under GDPR?

GDPR does not prescribe backup handling explicitly. The common, defensible approach is to delete from live systems immediately, document a fixed backup retention period after which the data ages out, and ensure restored backups re-apply pending deletions. Consult counsel for your specific situation.