Security isn't a feature you bolt on before a big enterprise deal — it's a set of decisions you make in the first sprint. Here's the checklist we actually work through when building a SaaS product.
Most SaaS founders think about security the week a prospect's procurement team sends over a 40-page vendor questionnaire. By then, retrofitting things like proper access control, encryption, and audit logging into a codebase that wasn't built with them in mind is slow, expensive, and often incomplete. The teams that handle this well treat security as an architectural decision made in week one, not a checklist run before a sales call. Below is the actual sequence of decisions we walk through when a SaaS product is being built, roughly in the order they matter.
Authentication Is Not "Add a Login Form"
The single most common security gap in early-stage SaaS products isn't a clever exploit — it's sloppy authentication. A few things matter more than people expect:
- Password storage: passwords must be hashed with a slow, purpose-built algorithm (bcrypt, argon2, or scrypt), never encrypted or stored in any reversible form. This is table stakes, but it still gets missed in rushed builds.
- Session management: sessions need sensible expiry, secure cookie flags (
HttpOnly,Secure,SameSite), and a way to revoke a session server-side — not just delete a client-side token and hope for the best. - Multi-factor authentication: even a basic TOTP-based MFA option (Google Authenticator style) closes off a huge percentage of account-takeover attempts, and customers in regulated industries will often ask for it directly.
- Rate limiting on auth endpoints: login, password reset, and signup endpoints are the first things credential-stuffing bots hit. Without rate limiting, an attacker can quietly brute-force thousands of accounts before anyone notices.
If you're using a managed identity provider (Auth0, Clerk, Supabase Auth, AWS Cognito) rather than rolling your own, you get most of this by default — which is exactly why we lean toward managed auth for the majority of SaaS builds unless there's a specific reason to own it.
Authorization: The Part Everyone Gets Wrong
Authentication answers "who is this user." Authorization answers "what is this user allowed to touch" — and in multi-tenant SaaS, this is where the real damage happens. The classic failure mode is an insecure direct object reference: a URL like /api/invoices/8842 that returns invoice 8842 regardless of which tenant is asking for it, because the backend checks that the invoice ID exists but never checks that it belongs to the requesting account.
The fix is architectural, not a patch: every single query that touches tenant-scoped data should filter by tenant ID at the database layer, not just at the API layer. Two patterns work well:
- Row-level security at the database level (Postgres RLS is the standard example), so even a buggy application query physically cannot return another tenant's rows.
- A repository layer that always requires a tenant/account context as an argument, so it's structurally impossible to write a query that forgets it.
This matters more than almost anything else on this list because it's invisible until someone finds it — usually a customer poking around their own account, sometimes a security researcher, occasionally a much worse actor.
Encrypt Data in Transit and at Rest — Both, Not Just One
Encryption in transit (TLS/HTTPS everywhere, no exceptions, including internal service-to-service calls where possible) is now assumed by default on any competent hosting platform. What gets missed is encryption at rest: database volumes, backups, and file storage should all be encrypted at the storage layer at minimum. Cloud providers like AWS, GCP, and Azure make this close to a checkbox now — there's rarely a good reason to skip it.
For particularly sensitive fields — API keys, tokens, anything resembling payment data — application-level encryption on top of storage-level encryption is worth the extra engineering effort, so that even a database dump or a misconfigured backup doesn't hand over plaintext secrets.
Secrets Management: Get Them Out of Your Codebase
API keys, database credentials, and signing secrets ending up hardcoded in a repository is still one of the most common ways SaaS products get breached — often not through a sophisticated attack, but through a public GitHub repo or a leaked .env file. The baseline discipline here:
- Secrets live in a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler, or even your hosting platform's built-in environment variable store) — never in source control, never in Slack messages, never in plaintext config files committed to a repo.
- Secrets get rotated periodically and immediately after any team member with access leaves.
- Different environments (development, staging, production) use different credentials, so a leaked staging key can't touch production data.
This is cheap to do right from day one and genuinely painful to retrofit once fifteen services are all reading from the same hardcoded key.
Input Validation and the Classic Injection Attacks
SQL injection and cross-site scripting (XSS) are decades-old vulnerabilities, and they are still routinely found in new software — not because developers don't know about them, but because a single unvalidated input field slips through. The durable fixes:
- Use parameterized queries or an ORM that parameterizes by default. Never concatenate user input directly into a SQL string.
- Sanitize and escape any user-generated content before it's rendered back into HTML, particularly in places like comment fields, profile bios, or support tickets where users control freeform text.
- Validate input shape and type server-side, always — client-side validation is a UX nicety, not a security control, since it's trivial to bypass by calling the API directly.
Logging, Monitoring, and Knowing When Something Goes Wrong
A huge portion of the damage from a security incident comes not from the breach itself but from the delay in noticing it. Practical baseline:
- Log authentication events (logins, failed logins, password changes, permission changes) in an audit trail that's separate from application debug logs and that customers with compliance needs can eventually query.
- Set up alerting for anomalies — a sudden spike in failed logins from one IP, an API key suddenly making ten times its normal request volume, a user account attempting to access resources outside its normal pattern.
- Keep logs long enough to be useful in an investigation (a common baseline is 90 days minimum for security-relevant logs) without accidentally logging sensitive data like full card numbers or plaintext passwords into your own log files — which is its own quiet compliance problem.
Third-Party Dependencies Are Part of Your Attack Surface
Modern SaaS products are built on dozens to hundreds of open-source packages, and a vulnerability in any one of them is effectively a vulnerability in your product. Automated dependency scanning (GitHub's Dependabot, Snyk, or equivalent) catching known CVEs in your package.json or requirements.txt is close to free to set up and catches a meaningful share of real-world incidents before they're exploited. Pair this with a habit of actually reading and applying the patch updates it flags — a scanner that nobody acts on is just noise.
Data Minimization: Don't Collect What You Don't Need
The most secure data is data you never collected. Before adding a new field to a signup form or a new tracking event, it's worth asking whether the product genuinely needs it. Every field of personal data you store is a field you now have to secure, back up, and eventually explain to a customer, an auditor, or a regulator if something goes wrong. This is especially relevant for anything resembling payment information — the standard practice across the industry is to never store raw card numbers at all, and instead use a PCI-compliant payment processor (Stripe, Razorpay, and similar) that tokenizes card data so your own servers never touch it. PCI DSS is the industry standard specifically built around this kind of card-data handling, and letting a compliant processor absorb that scope is almost always the right call for an early-stage SaaS team rather than trying to build compliant handling in-house.
Role-Based Access Control Inside Your Own Team
External attackers get most of the attention, but a meaningful share of real SaaS data incidents involve someone on the inside — not necessarily maliciously, but through overly broad internal access that turns an honest mistake into a serious exposure. A support engineer who can query any customer's full data set to resolve one ticket, or a junior developer with production database credentials for a task that only needed staging access, are both examples of internal permissions exceeding what the actual job requires.
The fix is the principle of least privilege applied deliberately to your own team, not just to customer-facing permissions: define roles with the minimum access needed for that function, require a documented reason and time-bound approval for any temporary elevation beyond that, and review who has standing access to production data on a regular cadence rather than letting access accumulate indefinitely as people change roles or projects over time. This is also one of the first things enterprise security reviewers ask about, since it's a well-understood proxy for how seriously a vendor takes access discipline generally.
Compliance Frameworks You'll Eventually Be Asked About
As a SaaS product moves upmarket, prospects start asking about specific frameworks — SOC 2, ISO 27001, GDPR, HIPAA, depending on the customer's industry. It's worth understanding what these actually are before a sales conversation puts you on the spot: SOC 2 is an independent audit of your internal security controls and processes, conducted by a third-party auditor over a defined period, not something a company can self-certify. GDPR is a European data protection regulation that applies based on whose data you handle, not where your company is based. HIPAA governs health data specifically in the US market. Each of these is a genuine, verifiable status that requires actual audit work, documentation, and in most cases, a licensed third party's sign-off — not a claim to make lightly or prematurely.
The practical approach for a growing SaaS team is to build toward whichever framework your actual target customers require, starting with the underlying practices (access control, encryption, logging, incident response, vendor risk management) that most of these frameworks share regardless of which one you eventually pursue formal certification against. Getting the practices right early makes the eventual audit process — whenever the business is ready to formally pursue it — considerably less disruptive than trying to retrofit them under a customer's deadline.
Building a Practical First-90-Days Security Baseline
None of this needs to happen simultaneously, and a small team building a first version of a product genuinely doesn't need enterprise-grade security theater from line one. A realistic sequencing:
- Week 1: managed authentication, TLS everywhere, secrets out of the codebase, parameterized queries by default.
- Weeks 2–4: tenant isolation verified with actual test cases (not just code review — write a test that tries to access another tenant's data and confirm it fails), dependency scanning turned on, basic audit logging for auth events.
- First quarter: MFA available to users, alerting on anomalous activity, a documented incident response plan (even a one-page one — who does what if something goes wrong at 2am matters more than it sounds).
- As the customer base grows: formal security questionnaires start arriving from enterprise prospects, and having the above already in place turns what would be a scramble into a straightforward "yes, here's how" conversation.
When we scope a new SaaS build at Scult, this is roughly the order we work through it in — treating security as part of the initial architecture rather than a separate workstream bolted on later, because the cost of doing it upfront is a fraction of the cost of doing it after a customer's data has already been exposed. If you're mid-build and unsure how much of this is actually in place in your current product, that's a conversation worth having before your next enterprise deal, not after.
