Why This Matters Before You Are Forced Into It
Two of our earlier guides already touch adjacent ground here without covering what this guide covers. Our guide on software ownership, repository rights, and vendor lock-in covers GDPR's Article 20 data portability right specifically — your customers' right to export their own data. Our guide on technical due diligence covers a missing SOC 2 certification as one specific red flag an investor or acquirer checks for. Neither explains what SOC 2 actually certifies, what a realistic compliance baseline looks like for a company with no dedicated security team, or when any of this stops being optional and starts being a condition of closing a deal. That's what this guide covers.
Most compliance content online is written for one of two audiences: a company already large enough to have a dedicated security or compliance function, or a company facing an active audit deadline. Almost none of it is written for the founder building a first product, trying to figure out whether any of this actually applies to them yet, and if so, how much of it. That's the gap this guide is written for.
Does a first-time founder need to worry about SOC 2, GDPR, and CCPA from day one?
Not equally, and not all at once. GDPR applies the moment you have any users in the EU, regardless of your size. CCPA has specific revenue and data-volume thresholds that exclude many early-stage companies entirely. SOC 2 is not a legal requirement at all — it becomes relevant specifically when an enterprise customer's security review requires it, which is a business decision you can often see coming before it happens.
SOC 2, Actually Explained
What is SOC 2, and what does it actually certify?
SOC 2 is a framework developed by the AICPA (American Institute of Certified Public Accountants) that results in an independent auditor's report on how well a company's controls meet a defined set of criteria. It comes in two forms: Type I assesses whether controls are properly designed at a single point in time; Type II assesses whether those controls actually operated effectively over a period, typically six to twelve months. It is not a government certification and not legally required — it's a report your customers can request and evaluate.
The AICPA's own Trust Services Criteria define five possible categories a SOC 2 report can cover: Security, Availability, Processing Integrity, Confidentiality, and Privacy (AICPA & CIMA, “SOC 2”). Of these five, only Security — sometimes called the “Common Criteria” — is mandatory in every SOC 2 report; the other four are elected based on what's actually relevant to your product, a point consistently confirmed across named compliance-industry sources including Cherry Bekaert, Drata, and the Cloud Security Alliance. A company that doesn't process payments, for instance, has little reason to include Processing Integrity in its report scope, while a company handling healthcare or financial data would reasonably include Confidentiality or Privacy.
The Type I versus Type II distinction is worth understanding precisely, since the two answer different questions. Type I answers “are your controls designed correctly, as of this date” — it's a snapshot, achievable relatively quickly since it doesn't require an extended observation window. Type II answers the harder, more valuable question: “did those controls actually operate as designed, consistently, over the past several months” — which is why enterprise buyers increasingly ask for Type II specifically, and why it takes meaningfully longer and costs more to produce. A Type I report is a reasonable first milestone for a young company that needs to show something to an early enterprise prospect; a Type II report is what a more mature security review typically expects.
On realistic cost: per Vanta's own published guidance on SOC 2 audit costs, the audit fee alone typically runs $10,000 to $50,000, while the all-in first-year cost — including readiness work, the audit itself, and compliance tooling — typically runs $10,000 to $80,000 or more, with large enterprises using Big Four auditors reaching well into six figures (Vanta, “How much does a SOC 2 audit cost?”). Vanta's guidance also puts readiness time — the work required before an auditor can even begin — at roughly one to five months, depending on company size and whether a security consultant is brought in to help. It's worth being direct that this guide could not find a single authoritative source publishing separate, verified dollar figures specifically for Type I versus Type II costs; the honest, defensible statement is that Type II costs more than Type I because it requires auditing controls across an extended observation window rather than checking them once, not a specific numeric split between the two.
Compliance automation platforms — Vanta, Drata, Secureframe, and similar tools — exist specifically to reduce this cost and timeline by continuously monitoring the technical controls an audit checks, rather than requiring a company to manually assemble evidence from scratch each time. For an early-stage company without a dedicated compliance function, this category of tooling is frequently the difference between a SOC 2 process that's manageable alongside normal product work and one that consumes a founder's or an engineer's time disproportionately for months.
| Type I | Type II | |
|---|---|---|
| What it assesses | Control design, at a single point in time | Control design and actual operating effectiveness |
| Observation window | None — a snapshot | Typically 6–12 months |
| Relative cost | Lower | Higher — longer audit window means more auditor work |
| Best fit | A first milestone, or an early enterprise prospect that needs something to show now | A mature security review, or a renewal after Type I |
What a SOC 2 readiness process actually looks like
Beyond the cost and timeline figures above, it's worth understanding the actual shape of the work involved, since “readiness” is a vague word that hides a fairly concrete set of steps. It typically starts with scoping: deciding which of the five Trust Services Criteria actually apply to your product, since scoping too broadly adds unnecessary audit surface and cost. Next comes a gap assessment — comparing your actual current practices (access controls, change management, monitoring, vendor management, incident response) against what the chosen criteria require, and identifying what's missing. The remediation phase follows: implementing the specific controls the gap assessment identified, which for an early-stage company often means formalizing practices that already exist informally — writing down an access-review process the team already does ad hoc, for instance, rather than inventing something from scratch. Only once controls are actually in place does the observation period begin for a Type II report, followed by the audit itself, where an independent CPA firm examines evidence and produces the final report. Compliance automation platforms streamline this entire sequence primarily by continuously collecting the evidence an auditor needs, rather than requiring someone to manually screenshot and document each control at audit time.
Who actually asks for it, and in what form
The request for a SOC 2 report rarely arrives as a single, simple ask. It usually shows up first as a vendor security questionnaire — a spreadsheet or portal-based form, sometimes running to dozens or hundreds of questions, asking about specific controls: how access is provisioned and revoked, whether data is encrypted at rest and in transit, how incidents are detected and reported, whether background checks are performed on employees with data access. A completed SOC 2 report answers a large share of these questions at once, in a format the reviewing security team already knows how to evaluate quickly — which is precisely why having one accelerates a sales cycle rather than just satisfying a formality. Without one, a founder or engineer typically ends up answering each question individually, for every enterprise prospect, which is both slower for that specific deal and a recurring tax on engineering time across every future enterprise conversation.
When SOC 2 Becomes a Sales Requirement
When does SOC 2 actually become necessary, rather than optional?
There's no universal trigger, but the pattern is consistent: it becomes necessary the moment a specific enterprise prospect's security or procurement team sends a vendor security questionnaire that either requires a SOC 2 report directly or asks detailed control questions a SOC 2 process would already have answers to. Vanta's 2025 State of Trust Report, surveying 3,500 business and IT leaders, found the time organizations spend on compliance-related tasks has risen to 11 working weeks a year, up from 10 the year before — a real, measured sign that this burden is growing, not shrinking.
It's worth being precise here about what this guide could and couldn't verify, since a specific, dramatic statistic on this exact question circulates widely without a traceable source. A claim that “83% of enterprise buyers require SOC 2 before signing, rising to 91% at large companies” appears across marketing and SEO content attributed to Vanta, but could not be confirmed against any primary Vanta report or page during this guide's research — it does not appear in Vanta's own published Trust Maturity Report, and no independent source corroborates it. This guide deliberately excludes that figure rather than repeating an unverifiable statistic.
What is verifiable, from Vanta's 2025 State of Trust Report (a real, named, dated survey conducted by Sapio Research across the US, UK, France, Germany, and Australia): 55% of surveyed organizations say security risks have never been higher, time spent on compliance tasks has risen year over year, 9% of respondents spend 21 or more hours a week specifically on security compliance work, and 48% say strong security practices actively drive customer trust. Read together, this is solid, real evidence that compliance burden and buyer scrutiny are both rising, even without a single, clean “X% require SOC 2” statistic to cite.
The practical, founder-facing version of this pattern is one you can watch for directly in your own sales pipeline, rather than relying on an industry-wide statistic: the first time a prospect's security team sends a formal vendor questionnaire, or explicitly asks “do you have a SOC 2 report,” is a reliable, early signal that this specific segment of your market — typically larger, more risk-conscious enterprise buyers — is going to keep asking the same question of every vendor at your stage going forward. Treating the first questionnaire as an early warning, rather than a one-off request, is the difference between starting a SOC 2 process on your own timeline versus starting it under deal-closing pressure with a specific prospect watching the clock.
GDPR: The Realistic Baseline for a Small Company
Does a small startup need a Data Protection Officer under GDPR?
Almost never, unless the company's core activity involves large-scale, systematic monitoring of people, or large-scale processing of special-category data (health, biometric, criminal-record data, and similar). GDPR Article 37 sets no company-size or revenue threshold for the DPO requirement — it's based entirely on the nature and scale of the data processing itself, not headcount.
This is worth stating precisely because the DPO requirement is one of the most commonly misunderstood parts of GDPR among founders. Article 37(1) requires a Data Protection Officer only when the organization is a public authority, or when its core activities require regular and systematic monitoring of data subjects on a large scale, or its core activities involve large-scale processing of special-category data. A five-person startup building, say, a genomics or mental-health product that processes sensitive health data at real scale could trigger this requirement early; a two-hundred-person company processing ordinary customer account data typically would not. It's also worth explicitly separating this from a different, frequently confused number: the 250-employee threshold some founders have heard about actually comes from Article 30's records-of-processing requirement, not Article 37's DPO requirement — the two are unrelated obligations that happen to get conflated in casual conversation.
The requirement that actually applies from day one, regardless of size, is establishing a documented legal basis for processing personal data before you process it. GDPR Article 6(1) sets out six lawful bases: consent, contract necessity, legal obligation, vital interests, public task, and legitimate interests. For most early-stage SaaS products, the relevant basis is usually contract necessity (processing needed to deliver the service someone signed up for) or legitimate interests (a narrower, documented justification for processing beyond the strict contract), rather than consent, which carries its own specific requirements around being freely given, specific, and easily withdrawable. The practical obligation this creates: before you collect and use any personal data, you should be able to name which of the six bases applies and why — not as a formality, but because Article 13(1)(c) requires disclosing that basis to users at the point of collection, typically through your privacy policy.
“Processing shall be lawful only if and to the extent that at least one of the following applies...”
— GDPR Article 6(1), setting out the six lawful bases for processing personal data
On real enforcement stakes, it's worth citing only figures that trace to a regulator's own published action, since fine amounts circulate widely with real accuracy problems attached. Two well-documented, verified cases: the Irish Data Protection Commission fined Meta Platforms Ireland Limited €91 million in September 2024 for storing certain user passwords in plaintext without encryption (Irish Data Protection Commission, September 27, 2024), and France's CNIL fined Google LLC and Google Ireland Limited €325 million in September 2025 for displaying ads within Gmail and setting advertising cookies during account creation without valid consent (CNIL, September 1, 2025). Both cases are instructive less for their scale — a startup isn't facing nine-figure fines — and more for what actually triggered them: a specific, concrete technical failure (unencrypted password storage) and a specific, concrete consent failure (processing before valid consent was obtained). Both are exactly the kind of basic, avoidable issue a small company is equally capable of creating, just at a smaller scale and with a smaller fine attached.
Data subject rights beyond portability
Our software ownership guide already covers Article 20's data portability right in depth, but GDPR grants several other data subject rights worth knowing as a practical baseline, since a small company needs a real process for handling each one, not just an awareness that they exist. The right of access (Article 15) lets a person request a copy of the personal data you hold about them. The right to rectification (Article 16) lets them correct inaccurate data. The right to erasure (Article 17, often called the “right to be forgotten”) lets them request deletion under specific conditions. None of these require an automated self-service system for a small company — a documented, manual process for responding to these requests within GDPR's required timeframe (generally one month, extendable in specific circumstances) is a legitimate, proportionate starting point. What matters is that the process exists and is actually followed, not that it's automated from day one.
The 72-hour breach notification requirement
One specific, time-sensitive GDPR obligation deserves its own mention because it's the exact scenario a written incident response plan is meant to prepare for: Article 33 requires notifying the relevant supervisory authority of a personal data breach within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals' rights and freedoms. Seventy-two hours is not a long window, particularly for a small team without a dedicated security function, and it starts running the moment you become aware of the breach — not the moment you've fully investigated it. This is precisely why having a written plan in advance matters more than its content might suggest on paper: the plan doesn't need to be sophisticated, but it needs to exist, because the alternative is trying to figure out who's responsible for what, and what the actual notification requirement even is, during the exact 72-hour window when that time is most scarce.
CCPA: Do You Even Need to Comply?
Does CCPA apply to every company with California customers?
No. A for-profit business must meet at least one of three thresholds to be covered: gross annual revenue of $26.625 million or more (effective January 1, 2025, adjusted annually for inflation), buying or selling the personal information of 100,000 or more California residents or households annually, or deriving 50% or more of annual revenue from selling or sharing Californians' personal information. Many early-stage companies meet none of these.
These thresholds come directly from the California Privacy Protection Agency's own published FAQ (California Privacy Protection Agency, FAQ), and they're worth knowing precisely because the numbers have changed over time and are commonly cited out of date. The original CCPA statute set a $25 million revenue threshold and a 50,000-consumer data-volume threshold that also included “devices” — language that no longer applies. The 2023 CPRA amendment raised the data-volume threshold to 100,000 consumers or households and dropped the “devices” language entirely, and the revenue threshold is now adjusted annually for inflation, reaching $26.625 million as of January 1, 2025. A founder relying on an older blog post citing “$25 million” or “50,000 consumers” is working from an outdated version of the law.
| Threshold | Current Figure | Effective |
|---|---|---|
| Annual gross revenue | $26.625 million or more | January 1, 2025 (inflation-adjusted annually) |
| Data volume | 100,000+ CA residents/households annually | Since the 2023 CPRA amendment |
| Revenue from data sales | 50% or more of annual revenue from selling/sharing personal information | Ongoing |
The practical implication is genuinely useful for a founder trying to prioritize limited time: unless your product already involves selling or sharing personal information as a meaningful part of your revenue model, or you're already operating at meaningful scale, you may not be legally required to build out a full CCPA compliance program yet. That doesn't mean privacy practices don't matter — GDPR's obligations apply regardless of size the moment you have EU users, and good privacy practice is good practice regardless of which specific law technically applies — but it does mean CCPA specifically is a threshold-triggered obligation worth checking against your actual numbers before assuming you need a full compliance program built around it on day one.
If CCPA does apply: what it actually grants consumers
For the subset of companies that do meet one of the thresholds above, CCPA (as amended by the CPRA) grants California residents several specific rights worth knowing in outline: the right to know what personal information a business collects and how it's used, the right to delete personal information collected from them (with specific exceptions), the right to correct inaccurate personal information, and the right to opt out of the sale or sharing of their personal information — the basis for the “Do Not Sell or Share My Personal Information” links visible on many consumer websites. A business covered by CCPA needs to provide an actual, working mechanism for each of these rights, not just a policy statement claiming to honor them. For a company below the applicability thresholds, none of this is a current legal obligation — but it's worth tracking your own growth against these thresholds periodically, since crossing one during a growth phase is exactly the kind of compliance change that's easy to miss until an external party (a customer, a partner's legal team, an acquirer's diligence process) asks the question directly.
What a Privacy Policy Actually Needs to Say
What does a startup's privacy policy actually need to disclose?
At minimum: what personal data you collect, why you collect it (your legal basis, under GDPR), who you share it with (including third-party processors), how long you retain it, and how a user can exercise their rights (access, correction, deletion, and portability where applicable). A generic template that doesn't reflect your actual practices creates more legal exposure than having none at all, since it becomes evidence of a specific, documented misrepresentation.
The most common failure mode isn't an absent privacy policy — most companies have some version of one, often generated from a template early on and never revisited. The failure is a policy that describes practices the product no longer follows, or never followed precisely: a policy claiming data is “never shared with third parties” while the product actually sends analytics events to three different third-party tools, for instance. This mismatch matters for two independent reasons. Under GDPR and similar frameworks, an inaccurate privacy disclosure is itself a compliance gap, independent of whatever the underlying data practice actually is. And practically, an inaccurate policy is exactly the kind of inconsistency a diligence process or an enterprise security review is trained to look for — discovering that a company's public privacy commitments don't match its actual technical practices reads as a credibility problem that extends well beyond the specific discrepancy found.
A practical habit worth adopting: treat your privacy policy as a living document that gets updated whenever you add a new third-party tool, start collecting a new category of data, or change how data is used — not as a one-time document written before launch and never touched again. This is a small, ongoing maintenance cost that's dramatically cheaper than discovering, during a security review or a real incident, that your own public documentation doesn't match what your product actually does.
Common Early-Stage Compliance Mistakes
A consistent set of mistakes recurs across the sources describing what actually goes wrong for early-stage companies, and none of them require a large security team to avoid — they require attention at a point when attention is cheap. Having no privacy policy at all, or one that was copied from a template and doesn't actually match what the product collects and does with data, is the most basic and most common. Using third-party tools — a CRM, an analytics platform, an email marketing tool, a customer support platform — without checking their own compliance posture or signing a Data Processing Agreement is a second common gap; liability for how customer data is handled doesn't disappear just because a vendor, not your own team, is the one touching it. Collecting or using data without a clearly documented legal basis, or relying on vague or implicit consent rather than a specific, freely given one, is a third. Having no written incident or breach response plan is a fourth — not because a breach is likely, but because when one happens, legally required notification timelines start immediately, and improvising a response process under that pressure is far worse than having one already written.
The single pattern tying all of these together, described consistently across compliance-focused publishers covering this space, is treating compliance as unnecessary until a specific enterprise deal or security questionnaire forces the issue. The real risk this creates isn't primarily regulatory fines — for a small company, those are genuinely unlikely in the near term. The real risk is what one compliance publisher describes as “silent deal killers: missing records, vague consent, random data collection, and vendor chaos” — the kind of gap that doesn't generate a fine, but does generate a stalled or lost enterprise sale the moment a prospect's security team starts asking specific questions your company can't answer cleanly.
Write down your actual legal basis for processing
Before collecting any personal data, be able to name which GDPR Article 6 basis applies and disclose it in your privacy policy — this costs nothing but attention and closes the most common gap.
Confirm whether CCPA thresholds actually apply to you
Check your real revenue and data volume against the current $26.625M / 100,000-resident thresholds before building a compliance program sized for a law that may not yet apply to you.
Get a Data Processing Agreement from every vendor touching customer data
Your CRM, analytics tool, and support platform are all processing customer data on your behalf — a signed DPA is a five-minute ask most vendors already have a template for.
Watch for the first enterprise security questionnaire, and treat it as a signal
The first formal request for a SOC 2 report is a reliable early sign this will keep happening — starting the process on your own schedule beats starting it under deal-closing pressure.
How this differs when you sell to regulated industries
Everything above describes a realistic baseline for a general-purpose SaaS product. That baseline shifts meaningfully if your customers are themselves in a regulated industry, since their own compliance obligations often flow down to you as a vendor. A product selling into healthcare in the US will encounter HIPAA obligations indirectly — a healthcare customer legally cannot use a vendor that handles protected health information without a signed Business Associate Agreement, which imposes its own specific security and breach-notification requirements distinct from GDPR's. A product selling into financial services will encounter similar downstream requirements tied to frameworks like GLBA or, for payment handling specifically, PCI-DSS. The practical implication for a founder evaluating which market to target first: entering a regulated vertical early means accepting a materially higher compliance floor from day one, not something you can defer until later the way SOC 2 or CCPA can sometimes be deferred for a general-purpose product. This is worth factoring into a go-to-market decision explicitly, not discovering after your first regulated-industry prospect asks a question your product and contracts aren't yet equipped to answer.
Building compliance into your product from the start, not bolting it on later
The cheapest time to make a compliance-relevant decision is before the underlying system is built, not after. A data model that separates personal data from operational data cleanly, from the beginning, makes a later access or deletion request dramatically easier to fulfill than one where personal information is scattered across a dozen tables and third-party integrations with no clear map of where it all lives. Logging that captures who accessed what data, and when, is far cheaper to build in as a standard practice from day one than to retrofit onto a system that was never designed to answer that question. None of this requires anticipating every future compliance requirement in detail — it requires a small number of general, low-cost habits (clean data modeling, consistent access logging, documenting third-party data flows as they're added) that happen to make every future compliance question, whatever it turns out to be, meaningfully cheaper to answer.
A Practical Compliance Checklist
- 1
Write a privacy policy that actually matches what your product does
Not a generic template — a document that accurately discloses what data you collect, why, and what legal basis justifies it. This is the cheapest, highest-leverage fix available and the one most often skipped.
- 2
Get signed Data Processing Agreements from every vendor handling customer data
Your CRM, analytics platform, email tool, and support software are all processors acting on your behalf under GDPR — a DPA is standard, low-friction paperwork most established vendors already provide.
- 3
Write a basic incident response plan before you need one
A short, clear document naming who does what if a breach occurs and what the notification timeline requires — inexpensive to write now, expensive to improvise under real pressure.
- 4
Confirm your actual CCPA applicability against current thresholds
Check your real revenue and data volume against the $26.625M revenue / 100,000-resident thresholds rather than assuming CCPA does or doesn't apply based on outdated information.
- 5
Start SOC 2 readiness the first time it comes up in a sales conversation, not after losing a deal to it
A Type I report, or even documented progress toward one, is often enough to keep an enterprise deal moving while a full Type II process completes in parallel.
It's worth closing this section with a broader point that applies across every framework covered in this guide: compliance isn't really a fixed destination you reach once and then stop thinking about. GDPR, CCPA, and SOC 2 all describe an evolving relationship between your product and the data it touches, not a one-time checklist. As your product adds features, adds integrations, and grows into new markets, the specific data you collect and how it flows through your systems changes — and each change is an opportunity for a previously accurate privacy disclosure to quietly become inaccurate, or for a new vendor integration to introduce a data-processing relationship nobody documented. Building a habit of periodically re-checking your actual practices against your documented ones — even informally, even just once or twice a year for a small company — is a cheap, ongoing form of insurance against the exact kind of drift that turns a minor oversight into a real compliance gap by the time anyone notices it.
Frequently Asked Questions
What is the actual difference between SOC 2 Type I and Type II?
Type I assesses whether your security controls are properly designed at a single point in time — a snapshot. Type II assesses whether those controls actually operated effectively over an extended period, typically six to twelve months. Type II is more valuable to enterprise buyers and typically costs more and takes longer to produce.
How much does SOC 2 certification realistically cost for a small company?
Per Vanta's published guidance, the audit fee alone typically runs $10,000 to $50,000, with an all-in first-year cost (including readiness work and tooling) of $10,000 to $80,000 or more. Compliance automation platforms like Vanta, Drata, and Secureframe are commonly used to reduce this cost and timeline.
Does my startup need a Data Protection Officer under GDPR?
Almost certainly not, unless your core business activity involves large-scale, systematic monitoring of people or large-scale processing of special-category data like health or biometric information. GDPR Article 37 sets no company-size or revenue threshold — the requirement is based on the nature and scale of data processing, not headcount.
Does CCPA apply to every company that has customers in California?
No. A business must meet at least one threshold: gross annual revenue of $26.625 million or more (as of January 1, 2025), buying or selling personal information of 100,000 or more California residents annually, or deriving 50% or more of revenue from selling personal information. Many early-stage companies meet none of these.
Is there real data on how often enterprise buyers require SOC 2 before signing a contract?
A widely circulated statistic claiming 83% (or 91%) of enterprise buyers require SOC 2 could not be verified against any primary source and should not be cited. What is verifiable, from Vanta's 2025 State of Trust Report, is that compliance-related work has risen to 11 working weeks a year on average, up from 10 the year before — real evidence the burden is growing, without a single clean percentage to cite.
What is a legal basis for processing under GDPR, and why does it matter for a small company?
GDPR Article 6(1) requires every instance of personal data processing to rest on one of six lawful bases — consent, contract necessity, legal obligation, vital interests, public task, or legitimate interests. For most SaaS products, contract necessity or legitimate interests usually applies. This matters from day one, regardless of company size, and must be disclosed in your privacy policy.
What are the most common compliance mistakes early-stage companies make?
Having no privacy policy or one that doesn't match actual practices, using third-party vendors without a signed Data Processing Agreement, processing data without a documented legal basis, having no written incident response plan, and treating compliance as unnecessary until a specific enterprise deal forces the issue.
What actually triggers real GDPR enforcement, based on verified cases?
Two well-documented, verified cases illustrate the pattern: the Irish DPC fined Meta €91 million in September 2024 for storing passwords in plaintext, and France's CNIL fined Google €325 million in September 2025 for setting advertising cookies without valid consent. Both stemmed from specific, concrete, avoidable technical or consent failures — not abstract non-compliance.
Should a first-time founder pursue SOC 2 before it's explicitly requested?
Not necessarily immediately, but the first formal enterprise security questionnaire or explicit request for a SOC 2 report is a reliable signal that this will keep recurring with similar buyers. Starting the process on your own timeline, once that signal appears, beats starting it reactively under deal-closing pressure from a specific prospect.
How is this guide different from your Software Ownership and Technical Due Diligence guides on similar topics?
Our Software Ownership guide covers GDPR's Article 20 data portability right specifically. Our Technical Due Diligence guide covers a missing SOC 2 report as one red flag investors check for. This guide covers the practical compliance basics underneath both — what SOC 2 actually certifies, the realistic GDPR and CCPA baseline for a small company, and the specific mistakes that create risk before either topic becomes relevant.
How quickly must a company notify authorities of a data breach under GDPR?
Within 72 hours of becoming aware of the breach, unless it's unlikely to result in a risk to individuals' rights and freedoms, per GDPR Article 33. The clock starts at awareness, not after a full investigation — which is exactly why having a written incident response plan in advance matters more than its specific content.
What data subject rights does GDPR grant beyond data portability?
The right of access (a copy of the data held about them), the right to rectification (correcting inaccurate data), and the right to erasure or "right to be forgotten" (deletion under specific conditions), among others. A small company needs a real, documented process for handling each request within the required timeframe — it does not need to be automated from day one.
What actual rights does CCPA grant if my company is covered by it?
The right to know what personal information is collected and how it's used, the right to delete it (with exceptions), the right to correct inaccuracies, and the right to opt out of its sale or sharing — the basis for "Do Not Sell or Share My Personal Information" links. A covered business needs a working mechanism for each right, not just a policy statement.
What is the most common mistake in a startup's privacy policy specifically?
Not having one at all is less common than having one that no longer matches actual practice — often a template written before launch that claims data is never shared with third parties while the product has since added several third-party analytics or marketing tools. This mismatch is itself a compliance gap under GDPR, independent of the underlying data practice.
None of this requires a dedicated compliance team or a six-figure budget on day one. It requires knowing which obligations actually apply to your current size and market (GDPR, likely; CCPA, check your actual numbers; SOC 2, only once a buyer asks), and treating the cheap, foundational steps — an accurate privacy policy, signed vendor agreements, a documented legal basis, a written incident plan — as worth doing before they're forced by a stalled deal or a real incident, rather than after. The founders who find compliance stressful are usually the ones who ignored it until a specific prospect or a specific regulator made it urgent. The founders who find it manageable are the ones who did the cheap parts early, and only spent real money on the expensive parts — chief among them a SOC 2 audit — once a real, specific business reason to do so actually appeared.