If an enterprise buyer just sent you a security questionnaire and you have no security team, the first action is to write down what you already do in four areas: tenant isolation, audit logs, personal-data handling, and rate limiting. Most early-stage B2B SaaS teams already cover part of each, and the gaps are cheaper to close while the schema is still small than after your first enterprise deal stalls on them.
This post is the trust hub for the rest of the cluster. Each section answers a question buyers and auditors ask, links to a deeper article, and uses the projects I have actually built as examples rather than theory. Nothing here is legal advice, and where a rule is stated I link the primary source I read.
The cost of getting this wrong is measurable. IBM's Cost of a Data Breach Report 2026 puts the global average cost of a data breach at $4.99M, a 12% increase over the previous year and a record high. That is an average across large organisations, so a startup will not see that exact number, but it explains why buyers ask for evidence before they sign.
What does SOC 2 require for an early-stage SaaS?
SOC 2 is an independent auditor's report on your controls, and according to the AICPA it can cover Security, Availability, Processing Integrity, Confidentiality or Privacy at a service organisation.
For a startup, Security is the natural first scope (this is my recommendation, not an AICPA rule). The surprise is how much of the work is process rather than code. Auditors look for evidence that access is limited to what people need, that people are onboarded and offboarded on purpose, that changes go through review and leave a deploy trail, that vendors are assessed, that incidents have a documented response, and that data is encrypted. If you already use pull requests, a managed database and a deploy pipeline, you probably do several of these without having written them down as policies.
Type I or Type II first?
The two report types differ in what the auditor tests: Type I looks at whether controls are suitably designed as of a date, Type II at whether they operated over a period. Your auditor sets the exact scope and window, so ask them before you plan a timeline. My recommendation is to start with Type I when a deal needs a report, then let evidence accumulate.
The step-by-step version, including which policies you can draft yourself, is in the SOC 2 Type I 90-day checklist for SaaS startups. The short advice is to scope tightly and never write a control you cannot operate, because an auditor will compare the policy to reality.
How do you make a SaaS GDPR-compliant without a legal team?
You treat GDPR as a data-model problem first: know where personal data lives, be able to delete and export it per person, and keep a written record of what you process and which vendors touch it.
The EDPB's guide for small businesses states that when data subjects exercise a right, the controller must respond within one month. It describes the right to erasure (for example when data is no longer necessary, processing is unlawful or consent is withdrawn), the right of access to a copy of the data, and portability in a structured, commonly used and machine-readable format. On record-keeping, the EDPB guide says you must keep a written record of your processing activities, including in electronic form. The GDPR text on EUR-Lex was not reachable from my tooling during this refresh, so this post relies on the EDPB summaries above and does not quote article numbers or fine amounts. Have a lawyer confirm the details for your situation.
What do those rights mean for your schema?
Four design habits make the rights routine instead of a manual dig.
- Map every place personal data lives: primary tables, analytics, your email provider, backups and logs.
- Build one deletion operation and one export endpoint per person, and test them before a request arrives.
- Store consent as a record in the data model, not as a checkbox that vanishes after signup.
- Keep a register of the vendors that process data for you, and decide at setup whether any buyer will require EU data to stay in the EU, because region choice is hard to change later.
The schema patterns are in GDPR-ready B2B SaaS architecture.
How do you build the technical controls buyers ask about?
Three controls carry most of the weight: an audit log, rate limiting and tenant isolation, and each is cheaper to design in than to retrofit.
What is an audit log, and how should you store it?
An audit log is a record of meaningful actions (who did what, to which resource, when, and in which tenant) that the application writes but cannot quietly rewrite.
Enterprise buyers ask for it directly ("can an admin see who changed this setting?"), and it supports accountability for both SOC 2 and GDPR. The defining property is that entries are not editable through the normal application path. Once a row can be silently updated, the log stops being evidence and becomes an ordinary table that looks like one. In practice that means granting the app write permission but no update or delete, enforced at the database layer where your platform allows it.
A useful event records the actor, a stable action name such as subscription.canceled, the target resource and its ID, the tenant ID, a timestamp and some request context. Two tensions appear quickly. Write volume grows with traffic, so audit storage is usually separated from hot transactional tables. Admins filter by user, date range and action, so you index for those queries up front.
Retention is a policy choice you should make on purpose. Callidus, the React + Firebase clinic SaaS I built solo, uses audit logging with three retention tiers: 90 days for routine events, 1 year for financial events and 2 years for GDPR-sensitive events, with PATIENT_DATA_ERASED entries kept without expiry, according to the case study. Log the actor and tenant on every event from day one. Backfilling tenant attribution onto old rows after you go multi-tenant is a thankless migration.
The concrete schema and query patterns are in audit logs for B2B SaaS: schema and query patterns.
How do you protect an API from abuse and runaway cost?
You cap how many requests each caller can make, per tenant or API key, and return a clear 429 with a Retry-After header when they exceed it.
OWASP's API Security Top 10 (2023) lists Unrestricted Resource Consumption as a risk because missing limits enable denial of service and inflated operating costs. Its example scenarios include an SMS-backed password reset that an attacker automates, costing real money, and a GraphQL API where batching bypassed endpoint-level throttling. Its prevention list includes rate limiting tailored to business needs, throttling sensitive operations such as OTP validation and password recovery, and spending limits or billing alerts with third-party providers.
Which headers and status codes should you return?
RFC 6585 defines 429 Too Many Requests for a user who has sent too many requests in a given time, and says the response may include a Retry-After header. The IETF is also drafting standard RateLimit and RateLimit-Policy header fields so servers can advertise quotas; at the time of writing, that draft was still an active Internet-Draft (version 11, dated 23 May 2026), so treat the names as subject to change. Counters need a shared store when you run more than one server instance. Patterns you can copy are in rate limiting patterns for SaaS APIs.
Why is tenant isolation the foundation of all of this?
Every compliance claim assumes customer A cannot reach customer B's data, and that is safest when the database enforces it rather than every query remembering a WHERE tenant_id = ? clause.
On Postgres that means Row-Level Security. On Firebase it means per-tenant security rules. Callidus keeps everything under tenants/{tenantId}/ in Firestore, carries tenantId and role in JWT claims, and, per its case study, reports 100% Firestore rules coverage. Pizzeria Bestek, a React + Supabase project, uses Supabase Postgres with Row-Level Security on all tables. These are two different stacks enforcing the same principle at the data layer, which lets audit logs, GDPR deletion and confidentiality controls inherit a boundary they can trust.
The tenancy models and the RLS versus rules comparison are in multi-tenant SaaS architecture. Callidus also shows how far a solo build can go on the operational controls: native TOTP multi-factor authentication with no SMS, and Sentry configured with sendDefaultPii: false, per its case study. If secrets handling is your next gap, read secrets management and API key security for SaaS.
When should a startup invest in compliance?
Invest in the architecture from day one because it is cheap to build in and expensive to retrofit, and invest in the attestation when a real deal asks for it.
Isolation, audit logging and a clean deletion path add modest time to an MVP rather than a separate project, which is the approach in the SaaS MVP development guide. AI-assisted workflows help cover this checklist without slowing delivery, as I describe in AI-augmented development. The audit itself is a discrete spend you time to a revenue trigger. I do not publish a price for compliance work; for how it affects a project budget, see software development cost and pricing, and for what to look for when staffing it, hiring SaaS developers.
Payments add their own security surface. BookBed, my Flutter + Firebase + Stripe booking product, has subscriptions wired but not activated for paid traffic, so I will not claim production billing results from it. The general lesson is to let Stripe handle card data rather than building it yourself, as covered in SaaS billing and payments.
Which of the four areas would fail a buyer's questionnaire today? Pick that one and write down its current state this week. If you want a second pair of eyes on it, get in touch.