GDPR and CCPA: What Actually Matters If You're Collecting User Data

Founders tend to fall into one of two failure modes with privacy regulation. The first is ignoring it entirely until an enterprise prospect's legal team asks for a Data Processing Agreement, a European user submits a deletion request, or a regulatory inquiry arrives. At that point, the gap between where you are and where you need to be is large and urgent, which is an expensive place to be. The second failure mode is treating compliance as a binary, all-or-nothing project that requires a dedicated legal team, a full compliance program, and months of work — which leads to deferral until the company is bigger.

The reality is that for most early-stage companies, 80% of the legal exposure comes from 20% of the requirements. GDPR is 99 articles long. CCPA has its own complexity. But the requirements that create the most practical risk for a startup are narrow: no privacy policy or a misleading one, no way to fulfill deletion requests, no Data Processing Agreements with vendors, and sharing or selling user data without adequate disclosure. Getting those four things right eliminates the majority of your regulatory and civil exposure without requiring enterprise-grade compliance infrastructure.

The goal at early stage isn't full compliance — it's minimum viable compliance that covers the real risk and doesn't block commercial conversations. That's achievable with a few days of focused effort and outside legal review of your privacy policy. It doesn't require a privacy counsel retainer or a six-figure compliance platform.

GDPR applies to you if you have any users in the EU, regardless of where your company is incorporated. If a user in Germany signs up for your product, you have GDPR obligations. This surprises many US-based founders who assume GDPR is a European company problem. CCPA applies to for-profit businesses that do business in California and meet at least one of three thresholds: annual gross revenue over $25 million, buying or selling personal information of 100,000 or more California residents or households annually, or deriving 50% or more of annual revenue from selling personal information. Most early-stage B2B companies don't hit the CCPA threshold initially, but B2C companies with any California user base often do.

Two concepts matter more than almost anything else in GDPR. The first is the distinction between a data controller (you — the entity that determines the purpose and means of processing personal data) and a data processor (a vendor processing data on your behalf — your cloud database provider, your analytics tool, your email platform). You're responsible for what your processors do with your users' data, which is why Data Processing Agreements matter. The second concept is legal basis for processing: under GDPR, you need a documented legal reason for each type of data processing you do. For most SaaS products, the relevant bases are contractual necessity (processing needed to deliver the service the user signed up for) and legitimate interests (processing that benefits your business in ways users would reasonably expect). Consent is also a valid basis but is often overused and harder to rely on than founders assume.

Five concrete items cover the majority of early-stage exposure. First, have a privacy policy that accurately describes what you collect, why you collect it, who you share it with, and how users can exercise their rights. “Accurately” is the operative word — a privacy policy that says you don't sell data when you're sharing it with an advertising platform is worse than having no policy, because it creates a deliberate misrepresentation. Get it reviewed by outside counsel before publishing. Second, have a mechanism for users to request deletion of their data and be able to fulfill it. “Email us at privacy@yourcompany.com” is sufficient as a mechanism; the obligation is to actually execute the deletion across all your systems within the required timeframe (30 days under GDPR).

Third, execute Data Processing Agreements with every vendor that touches personal data. Walk through your vendor list: database provider, analytics tool, email platform, CRM, customer support platform, payment processor. Every one of these is a data processor under GDPR. Most have DPAs available on their website under “legal” or “privacy.” Fourth, don't sell or share personal data without explicit disclosure and, where required, consent. If you're sharing event data with an advertising platform for retargeting, that needs to be disclosed in your privacy policy. If you're selling data to a third party, that's a different level of obligation under both GDPR and CCPA.

Fifth, for GDPR specifically: document your legal basis for each type of processing. This doesn't need to be public-facing, but it needs to exist internally. A simple spreadsheet mapping each category of data processing to its legal basis is sufficient. This matters because if a regulator asks, you need to be able to produce it — and because the exercise of documenting it often surfaces processing you were doing without a clear legal justification.

The three gaps that create most of the legal exposure for startups are: no privacy policy or a misleading one (creates regulatory and civil liability, and blocks enterprise sales conversations), no ability to fulfill deletion requests (a GDPR violation every time a user requests deletion and nothing happens), and no DPAs with vendors (technically a GDPR violation for every EU user you have, and a blocking issue in enterprise procurement). Getting these three things right is minimum viable compliance. It won't pass a Big Four privacy audit, but it eliminates the most common blockers and the most acute legal risks.

Enterprise-grade compliance adds: a documented Records of Processing Activities (RoPA), data subject access request processes that can handle high volumes, formal privacy impact assessments for new features, a data retention and deletion policy with automated enforcement, cookie consent management with granular category controls, and regular third-party audits. None of this is necessary at seed or Series A unless you're selling into regulated industries or handling special category data. It becomes necessary as you close enterprise contracts with legal teams that ask for it, enter regulated verticals like healthcare or financial services, or grow to the point where privacy incidents carry meaningful regulatory attention.

The right frame is: what compliance posture do I need for the commercial conversations I'm having right now, and what do I need to build toward for the customers I'm targeting in 12 months? A Series A company selling into mid-market SaaS needs the minimum viable checklist plus the ability to produce a completed security questionnaire. A Series B company selling into enterprise financial services needs something much closer to enterprise-grade. Build toward where you're going, not just where you are — but don't build the enterprise program before you have the customers that require it.