What security does a SaaS startup actually need before its first customer?

Five things, because they are expensive to change later: how tenants are separated in the data model, who owns identity, where secrets live and how fast they can be revoked, what gets logged and for how long, and which country the data sits in. Everything else can wait until a customer or a regulator asks for it.

Do I need SOC 2 before I launch?

Almost certainly not. SOC 2 is a sales unlock, not a launch requirement, and a Type II report needs an observation window of three to twelve months of controls actually operating. Starting it before you have an enterprise buyer asking means paying for an audit of a product that is still changing shape.

What is the single most damaging security failure for a SaaS product?

A cross-tenant data leak, where one customer sees another customer's data. It is immediately visible to the customer who receives the wrong data, it is individually reportable, and unlike most incidents it cannot be explained away as a sophisticated attack. It is usually one missing condition in one query.

When should a SaaS founder hire someone for security?

Later than most founders fear and earlier than most leave it. The trigger is not headcount or revenue, it is when security work becomes recurring rather than occasional: continuous questionnaires, an audit to maintain, customer commitments to evidence. Until then the job is making a small number of decisions well, not staffing a function.

You Are the CISO Now

If your company has customers, it has a security function, and at your size it is you. Nobody assigns the role. You find out when an enterprise buyer sends a two hundred row questionnaire.

The job is smaller than it sounds. Five decisions are load bearing and expensive to reverse. The rest can wait until somebody asks.

The job nobody handed you

Every SaaS company has a security function. In a company of four hundred it is a team with a budget. In a company of four it is whoever last thought about it, which is to say it is you, part time, between things that feel more urgent.

This is not a gap you can close by working harder. It is a gap you close by accepting that the role exists and then doing the small number of things the role actually requires at your stage. That number is much smaller than the internet suggests. Most security advice is written for organizations with a security team, and applying it to a company of four produces either paralysis or theatre. The guidance that scales down best is written as practices rather than controls: NIST’s Secure Software Development Framework is the usual starting point.

The useful frame is this. A CISO’s job is not to make a company secure. It is to decide which risks the business will carry, make sure the expensive ones are not carried by accident, and be able to show the reasoning afterwards. That job is entirely doable by one founder who has thought about it for an afternoon.

Five security decisions you make once

Almost everything in security can be fixed later at a cost roughly proportional to how much later. Five things cannot, because they are load bearing. Change them after you have customers and you are not making a decision, you are running a migration, with data, contracts and downtime attached.

Decision	Cost now	Cost after 100 customers
Tenant separation	an afternoon	a rewrite of the data layer
Identity ownership	a vendor choice	a forced migration of every login
Secrets handling	a setup step	rotating every credential blind
Logging	a config	evidence that does not exist
Data location	a dropdown	renegotiating contracts

How tenants are separated. One customer must never be able to see another customer’s data, which is what tenant isolation means in practice. The question is not whether you filter by customer, it is whether the database refuses to return the wrong rows even when the application forgets to ask correctly. Decide this before the data model sets, because it is the one failure on this list that can end the company outright.

Who owns identity. Passwords, sessions, resets, and second factors are a solved problem you cannot differentiate on and can only lose at. The real decision is not build versus buy, it is which provider you can live with when an enterprise buyer demands single sign on and directory sync, because that is where the pricing and the migration pain sit.

Where secrets live. Every product holds credentials it did not choose: a database password, a payment provider’s live key, a cloud account. The question that matters is not how they are stored but how quickly they can be cancelled. A leaked key is a problem for exactly as long as it stays valid.

What gets logged. Enterprise buyers will eventually ask who accessed what, and when. If you were not recording it, there is no way to answer retroactively, because logs are the one control that cannot be applied to the past. Decide now what you capture and how long you keep it, and let the cost of storage be the constraint rather than the cost of remembering to turn it on.

Where the data physically sits. Region is a dropdown on day one and a contractual commitment on day two hundred. European buyers will ask, and a promise you made in a sales call before checking is a promise that becomes a migration.

What a SaaS founder can safely ignore

The other half of this job is refusing work, and at your stage most of the available security work is not yet worth doing.

SOC 2, until a buyer asks. It is a sales unlock, not a launch requirement, and the Type II report buyers actually want requires months of controls operating on a product whose shape is still changing.
A penetration test, until there is something stable to test. A test against a product that will look different in six weeks buys you a report, not security.
A security policy library. Twenty policies nobody reads are worse than none, because they create commitments you are visibly not meeting.
Most tooling. A dashboard of alerts nobody has time to read is a cost with the appearance of a control.

None of this is permanent. Each item has a trigger, and the trigger is almost always a customer asking rather than a date arriving.

Security questions to ask yourself

These are the questions a board would ask you, if you had a board asking.

If one customer could see another customer’s data tomorrow, what would have to have gone wrong, and what would stop it?
If our production database credentials leaked right now, how long until they are useless to whoever has them?
Who on this team can read customer data, and could I prove that answer to someone who did not believe me?
If a customer asked what we did with their data eight months ago, do the records exist?
What have we already promised a customer in a sales call that we are not actually doing?

The last one catches more companies than any attacker does. It is also the only one on this list that gets worse the longer you leave it, because the promises accumulate.

The rest of this handbook

The parts are sequenced by the stage you hit them, not by subject. Each one appears here as it is published, and the list at the foot of this page links the parts that are already live.

Before your first customer

You are the CISO now
Tenant Isolation: the bug that ends a SaaS company
Authentication: what to buy and what to never build
Secrets, and the file that reached GitHub
Production access for a team of three

Your first enterprise buyer

The security questionnaire: answering without lying
SOC 2 without a compliance team
Audit logs your customers will actually ask for
Your dependency tree is your attack surface
Backups, restores, and the recovery time you can honestly promise

Running it

Incident response for a team of three
Shipping AI features safely

Start here. Take the five decisions above and write one line on each saying what you actually chose. The ones you cannot answer are not decisions you made, they are defaults you inherited, and that list is your roadmap.

You do not need a security programme. You need five decisions made deliberately and written down, and the discipline to refuse the rest until someone asks.