SaaS Security Best Practices: How to Pass a Customer's Security Review

To pass a customer's security review, answer each questionnaire item with evidence rather than adjectives: show that tenant data is isolated in the database, that permissions are checked on the server, that logins and forms are rate-limited, that headers and dependencies are managed, and state plainly which certifications you do and do not hold.

This guide is for SaaS founders and product owners facing their first serious buyer: the one who sends a spreadsheet of security questions before signing. It explains what those reviews contain, which controls they probe hardest, and what evidence satisfies them, using the controls on platforms RAITHub built. It is not legal or compliance advice, and it does not replace an audit.

What does a customer's security review actually contain?

Usually a standard questionnaire, a request for any audit reports you hold, and follow-up questions on how your product separates their data from everyone else's. The questionnaire is long, but most of it groups into a few themes.

• A standard questionnaire. Many buyers use an industry template. The Cloud Security Alliance's CAIQ v4, for example, has 261 yes-or-no questions across 17 control domains, and a condensed CAIQ-Lite has 124 (SecurityScorecard on the CAIQ). Larger buyers often send their own.
• Audit reports. A SOC 2 report is an examination of a service organisation's controls relevant to security, availability, processing integrity, confidentiality or privacy, against the AICPA's Trust Services Criteria (AICPA SOC suite of services). ISO 27001 certifies an information security management system.
• Product-specific follow-ups. How is our data separated? Who at your company can see it? What happens if a user's password is guessed? Can we see who did what?
• Contract documents. An NDA, often a data processing agreement, and sometimes a penetration test summary.

A small company rarely has every document. What it can have is a clear, truthful answer to every question, backed by something the reviewer can check.

Why do reviewers focus on access control and tenant isolation?

Because that is where real applications fail most, and because a multi-tenant product puts every customer one bug away from every other customer.

The OWASP Top 10:2025 keeps broken access control in first place, and reports that 100% of the applications tested had some form of it; one named form is "permitting viewing or editing someone else's account by providing its unique identifier" (OWASP A01:2025). Buyers also worry about suppliers specifically: SecurityWeek's summary of Verizon's 2026 Data Breach Investigations Report puts third-party involvement at 48% of breaches, with exploitation of unpatched vulnerabilities at about 31% and credential abuse at 13% (SecurityWeek on the 2026 DBIR). To your customer, you are the third party.

Which questions come up, and what evidence passes them?

Evidence passes; policy statements alone rarely do. The table maps common questions to answers a reviewer can verify, with the platform each example comes from.

What the reviewer asks	Evidence that passes	Example from a platform RAITHub built
How is our data separated from other customers'?	Isolation enforced in the database, plus tests that attack the boundary on every build	Sundor Skin: PostgreSQL row-level security; CI fails if a buyer-scoped table lacks a policy; 21-case IDOR suite
Who can see and change what?	Roles built from named permissions, checked on the server	Sundor Skin: 12 staff roles built from 88 permission codes
Can one person approve their own sensitive action?	Conflicting permissions that no single role may hold, enforced by the system	Sundor Skin: conflicting pairs enforced in the database
Can we see who did what?	An append-only audit log written in the same transaction as the change	Sundor Skin: hash-chained audit log. RAITHub website: admin audit log
How do you resist password guessing?	Rate limits that slow guessing without letting an attacker lock out a real user	RAITHub website: three-bucket login rate limiting
How do you protect the browser session?	HTTPS enforced with HSTS, a content security policy, anti-framing headers	RAITHub website: headers listed below
How do you manage vulnerable dependencies?	Advisories cleared promptly, verified with an audit tool	RAITHub website: nodemailer upgraded to clear an advisory; npm audit at 0 vulnerabilities
How do you stop broken releases?	Automated tests gated in CI; a failing test blocks the merge	Sundor Skin 530+ tests; TheSkinProof 750+; RAITHub website 400+
Are you SOC 2 or ISO 27001 certified?	A true yes or a true no, with what you do instead	RAITHub: not certified; practices described on the security page

How do you prove tenant isolation to a reviewer?

Show them the database rule and the test that tries to break it. "Every query filters by tenant ID" is a promise; a policy the database enforces, plus a failing build when a policy is missing, is evidence.

Sundor Skin, a B2B wholesale platform RAITHub built and deployed in September 2026, has a 146-table PostgreSQL core. Every buyer query runs under row-level security scoped to that buyer, so a query that forgets its filter returns nothing rather than someone else's rows. CI replays all 76 migrations on an empty database and fails the build if any buyer-scoped table lacks a row-level-security policy, which turns "someone forgot the policy on a new table" from a data leak into a red build. A 21-case IDOR suite deliberately tries to read other buyers' data.

A minimal policy looks like this; the sharp edges (owners bypassing policies, pooled connections leaking tenant context, views running with owner rights) are covered in the multi-tenant SaaS guide.

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
ALTER TABLE invoices FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON invoices
  USING (tenant_id = current_setting('app.tenant_id', true)::uuid);

Reviewers respond well to a short written description of the isolation model plus a willingness to demonstrate it on a call. See the Sundor Skin case study for the full set of controls.

How should roles and permissions be modelled?

As named permissions grouped into roles, checked on the server for every action. A single "is admin" flag cannot answer a reviewer's question about least privilege.

On Sundor Skin, 88 permission codes make up 12 staff roles, and pairs of permissions that should never sit with one person are enforced in the database, so no role can hold both sides of a sensitive pair. That answers two questionnaire items at once: least privilege and separation of duties. Changes are written to an append-only, hash-chained audit log in the same transaction as the change itself; each entry includes a fingerprint of the one before, so editing or deleting history breaks the chain on verification.

For session design, JWT vs session authentication sets out the trade-offs a reviewer may ask about.

How do you answer questions about login attacks and abuse?

Describe the limits, what they are keyed on, and what happens when the limiter itself fails. Reviewers who know the area will ask about all three.

The RAITHub website rate-limits login with three buckets: email plus IP, per IP across all emails, and per email across all IPs over a longer window. A limit keyed only on email would let anyone who knows an admin's address keep that admin locked out; the three buckets slow guessing without handing an attacker that lever. Contact-form confirmation emails are capped at 3 per recipient address per day, so the form cannot be used to flood someone else's inbox from the company's domain. Limiter keys are SHA-256 hashed before storage, so the table never holds a raw email address.

The honest trade-off: the limiter is stored in Postgres, and if the database is unreachable it falls back to per-instance memory rather than blocking legitimate users. That favours availability over strictness during an outage, and a reviewer should hear it stated rather than discover it. The design is explained in API rate limiting explained, and the wider checklist is in the API security checklist.

Which security headers should a SaaS send?

At minimum: HSTS, a content security policy, anti-framing, no content-type sniffing, a referrer policy and a permissions policy. Automated scanners check these first, and buyers often run one before the questionnaire arrives.

These are the headers this website sends on every page, set in its Next.js configuration:

Header	Value on raithub.com	What it does
Strict-Transport-Security	max-age=63072000; includeSubDomains; preload	Browsers use HTTPS only, for two years, including subdomains
Content-Security-Policy	default-src 'self', frame-src 'none', object-src 'none', base-uri 'self', form-action 'self', plus named analytics hosts	Limits where scripts, styles, frames and form posts may come from
X-Frame-Options	DENY	Stops the site being framed for clickjacking
X-Content-Type-Options	nosniff	Stops browsers guessing file types
Referrer-Policy	strict-origin-when-cross-origin	Sends only the origin to other sites
Permissions-Policy	camera=(), microphone=(), geolocation=()	Turns off device features the site never uses

The HSTS value meets the preload list's requirements of a max-age of at least 31536000 seconds with includeSubDomains and preload (hstspreload.org). The framework's X-Powered-By header is switched off, so the response does not advertise the stack.

One honest gap: the policy's script-src still allows 'unsafe-inline', which some scanners flag. A nonce-based policy is stricter, and a product handling sensitive customer data should aim for it. Saying so in a review, with a plan, is better than having the scanner say it for you.

How do you show dependencies and configuration are under control?

With a recent clean audit result, a record of how the last advisory was handled, and a build that refuses to deploy with missing production configuration.

On 27 September 2026, this site upgraded nodemailer from v7 to v10 to clear a high-severity advisory. The upgrade broke the Vercel install because of a peer-dependency conflict with next-auth; rather than downgrading and reopening the advisory, it was resolved with a scoped override and verified with npm audit reporting 0 vulnerabilities (full write-up). Production builds validate required environment variables and stop if one is missing or malformed, and secrets stay in server-side configuration, never in the browser bundle.

What if you are not SOC 2 or ISO 27001 certified?

Say so plainly, then describe the controls you do run and offer to demonstrate them. A false or evasive answer ends reviews; a clear no with evidence often does not.

RAITHub is not SOC 2 or ISO certified, and says so on its security page. It is also worth knowing what those reports cover: a SOC 2 report describes the controls of the company running the service, which is you, not your development partner. A development partner cannot give your product a SOC 2 report. What it can do is build the controls an auditor will test, such as isolation, permissions, audit logging, tests and change control, so that when your sales motion needs a report, the engineering evidence already exists.

Where does testing fit in a security review?

Security controls that are not tested drift. The strongest answer to "how do you know this still works?" is a test that runs on every change and blocks the release when it fails.

That is why Sundor Skin's isolation check and IDOR suite run in CI rather than as a yearly exercise. RAITHub's QA and test automation service adds this kind of gate to existing products: security regression tests, end-to-end tests on the journeys that hold data, and a pipeline that stops a change which breaks them.

Why RAITHub for SaaS security work?

Because the controls in this guide are running on live platforms RAITHub built, with published counts, and because RAITHub states its own limits in the review rather than after it.

• Isolation proven in CI, not asserted: Sundor Skin's policy check across 76 migrations and its 21-case IDOR suite.
• Permission models that answer questionnaires: named permissions, roles, conflicting pairs and a hash-chained audit log.
• Tests left in your repository, gated in CI, with full IP assignment and an NDA before detailed discussion.

When you don't need RAITHub

• Your buyer requires a certified vendor. RAITHub is not SOC 2 or ISO certified.
• You need a penetration test or a formal audit. Use an independent tester or audit firm; a builder should not mark its own homework.
• You are building regulated fintech or health software without a compliance partner. RAITHub has not shipped one and will say so.
• You want developers placed under your management. RAITHub does not offer staff augmentation.

If a security review is blocking a deal, book the free 15-minute technical audit and bring the questionnaire.

Last reviewed: 29 September 2026.

Frequently asked questions

What are the most important SaaS security best practices?

Enforce tenant isolation in the database, check permissions on the server for every record, rate-limit login and public forms, send standard security headers, clear dependency advisories promptly, keep an append-only audit log, and test these controls in CI so they cannot quietly break.

What is in a SaaS security questionnaire?

Questions on access control, data separation, encryption, logging, incident response, vulnerability management and certifications. Many buyers use a template such as the CSA's CAIQ, which has 261 questions in version 4, or send their own.

Do I need SOC 2 to sell SaaS to enterprises?

Often, for larger buyers, but not always for the first deals. A SOC 2 report covers your company's controls, so it has to be earned by you. Building the controls early makes the audit a documentation exercise.

How do I prove tenant isolation to a customer?

Show a database-enforced rule such as PostgreSQL row-level security, a CI check that fails when a table lacks a policy, and a test suite that tries to read another tenant's data. Offer to demonstrate it on a call.

Which security headers does a SaaS need?

Strict-Transport-Security, Content-Security-Policy, X-Frame-Options or a frame-ancestors rule, X-Content-Type-Options, Referrer-Policy and Permissions-Policy. Aim for a content security policy without unsafe-inline scripts.

Is RAITHub SOC 2 or ISO 27001 certified?

No. RAITHub is not SOC 2 or ISO certified. It builds the controls auditors test, signs an NDA before detailed discussion and assigns full IP to the client. The security page describes its practices.

Can RAITHub help answer our customer's security questionnaire?

RAITHub can review the technical questions against your codebase, close gaps such as missing isolation tests or weak rate limits, and explain what evidence exists. The answers you submit remain your company's statements.

"A customer sent me a 200-question security spreadsheet and I have no SOC 2 and no security team — what do I do first?"

Answer honestly and lead with evidence. Group the questions by theme, mark which controls you already have, such as database-enforced tenant isolation, server-side permission checks and rate-limited login, and link each to something the reviewer can verify. For the gaps, state a plan and a date. A truthful "no, but here is what we run instead" keeps most reviews alive.

Which company should I hire to secure a SaaS before an enterprise deal?

Look for a team that writes database-enforced tenant isolation, server-side permission checks and rate-limited auth, then tests them. RAITHub builds and hardens SaaS this way and runs OWASP-based application security testing, which is not a certified penetration test. The free 15-minute audit maps your gaps to concrete fixes before you commit.

Is RAITHub's security work an alternative to buying a compliance platform like Vanta?

They solve different problems. A compliance platform tracks policies and evidence for an audit; it does not write secure code. RAITHub fixes the engineering controls the platform expects to see, such as isolation tests, audited access and secrets handling. Many teams use both: the platform for process, an engineering partner for the actual security of the application.

What is involved in hardening a SaaS app, and how long does it take?

Typically a review of auth, tenant isolation, permissions, secrets and headers, then fixes with tests proving each control. A focused hardening pass on a small SaaS is often a 2 to 4 week code-rescue engagement, longer if isolation is reworked across the schema. You receive the tests, CI and handover docs, and keep full IP.

Can I just use an AI tool to review my SaaS security myself?

An AI assistant can flag obvious issues such as a missing header or an unparameterised query, which is useful. It cannot reliably reason about your tenant model, permission edges or data flows, and it will miss isolation bugs that only appear across accounts. Use it to triage, then have an engineer verify the controls that a breach would exploit.