Your SaaS Security Checklist Before Going Enterprise

You have been selling to small businesses and mid-market companies. Now you have an enterprise prospect with 5,000 employees and a $200K ACV deal on the table. There is just one catch: their security team sent you a 300-question security assessment, and you have answers for maybe 40 of them.

This is the moment every SaaS startup faces. Here is the checklist you need to complete before you can confidently sell to enterprise customers.

Authentication and access control

• SSO support (SAML 2.0 and/or OIDC). Enterprise customers require SSO. They will not create individual username/password accounts. Implement SAML 2.0 integration with Okta, Azure AD, and Google Workspace at minimum.
• Role-based access control (RBAC). Your application needs granular permissions, not just "admin" and "user." Enterprise customers need to control who can view, edit, delete, and export data.
• Multi-factor authentication (MFA). Support TOTP-based MFA at minimum. Bonus points for WebAuthn/FIDO2 support.
• Session management. Configurable session timeouts, forced logout on password change, and the ability to view and terminate active sessions.

Data security

• Encryption at rest. All customer data must be encrypted at rest using AES-256 or equivalent. Use your cloud provider's native encryption (AWS KMS, Google Cloud KMS) for the easiest implementation.
• Encryption in transit. TLS 1.2 minimum, TLS 1.3 preferred. No mixed content. HSTS enabled.
• Data residency. Can you guarantee where customer data is stored? Enterprise customers, especially in regulated industries, need data to stay within specific geographic boundaries.
• Data retention and deletion. You need a documented process for how long you retain data and how you delete it when a customer churns. Include a data processing agreement (DPA) in your contract.

Infrastructure security

• Network segmentation. Your production environment should be in a separate VPC/network from development and staging. No developer should be able to access production data from their laptop.
• Vulnerability management. Regular scanning of your application (DAST), your code (SAST), and your dependencies (SCA). Have a process for patching critical vulnerabilities within 24 hours.
• Incident response plan. Documented, tested, and with defined SLAs for notification. Enterprise customers typically require notification within 24 to 72 hours of a confirmed breach.
• Backup and recovery. Automated backups, tested restore procedures, and a documented RTO/RPO. Your customers will ask about this.

Compliance

• SOC 2 Type II report. This is the baseline. Start with Type I if you do not have it yet, but plan for Type II within 12 months.
• Penetration testing. Annual third-party pen tests with remediation evidence. Enterprise security teams will ask for the executive summary.
• Vendor management. Document your third-party vendors, their security posture, and how you evaluate them. Enterprise customers want to know who has access to their data downstream.

Operational readiness

• SLA with uptime guarantees. 99.9% is table stakes. Define what happens when you miss it (service credits, escalation procedures).
• Audit logging. Every user action should be logged with who, what, when, and from where. Enterprise customers need this for their own compliance requirements.
• A dedicated security page. Create a /security page on your website that outlines your security practices, certifications, and how to report vulnerabilities. This saves you time answering the same questions repeatedly.

How to prioritize

You do not need all of this on day one. Prioritize based on what your specific enterprise prospect requires. SSO and SOC 2 are almost always non-negotiable. Encryption and access controls come next. Audit logging and advanced compliance can come later if needed.

The key is to start early. Every item on this list takes time to implement properly. If you wait until an enterprise deal is in the pipeline, you will be scrambling to build in weeks what should have been built over months.

Need help getting enterprise-ready? Check out our security services and compliance services or book a call.

The questions behind the checklist items

Ticking an item and defending it are different exercises. Enterprise security analysts have read hundreds of vendor responses and they probe in predictable places. Knowing where saves you a fortnight of back and forth.

On tenant isolation, they rarely accept "customer data is separated." They ask how. If you use a shared database with a tenant identifier column, they want to know what prevents a query from omitting that filter, and the honest answer needs to be a mechanism rather than a promise. Row-level security enforced by the database, an application layer that cannot construct an unscoped query, or automated tests that assert cross-tenant access fails. If your only answer is developer discipline, say so plainly, because an analyst who catches you overstating this will re-read everything else you wrote.

On encryption at rest, the follow-up is always key management. Who can access the key material, whether keys are per-tenant or shared, how rotation works, and whether your own staff can decrypt customer data. Cloud provider managed keys are a perfectly good answer. Pretending you have a hardware security module when you have a managed key service is not.

On administrative access, expect a question about whether your engineers can read customer data in production and under what circumstances. Most SaaS companies can, for support reasons. The acceptable position is that access is limited to named people, requires a justification, is time-bounded, and is logged in a place the engineer cannot edit. The unacceptable position is that everyone in engineering holds standing production credentials, which is still surprisingly common and shows up immediately in an access review.

On offboarding, they will ask how long it takes to remove a departing employee's access across all systems. The real answer for most startups is that email and the cloud console get handled the same day and eleven software-as-a-service tools do not. Build the list of every system a leaver has access to before someone asks for it.

Buying a penetration test that is worth showing

Annual testing appears on every checklist and the quality range in the market is enormous. A cheap automated scan with a report cover page will be recognized as such by any competent reviewer, and producing one can be worse than producing nothing.

Scope is what determines value. An unauthenticated test against your marketing site tells a buyer nothing about the product they are considering. The test that matters is authenticated, covers the application's authorization model across multiple roles and multiple tenants, includes the API rather than only the browser interface, and specifically attempts the cross-tenant access that keeps their analyst awake. Write that scope into the engagement, and expect the testers to ask for accounts at several privilege levels.

Ask three things of any firm before you engage them. What does the deliverable contain beyond a findings list, meaning is there an executive summary you can share externally without exposing your architecture. Is retesting of fixed findings included, or billed separately, because a report full of open criticals is a worse artefact than no report. And who does the testing, named people with demonstrable research output rather than a pool. Published vulnerability research is a reasonable proxy for capability; we have five published CVEs, one of them a CVSS 9.1 in the Mirai botnet, across more than twenty penetration tests, and it is a fair question to ask of anyone you hire.

Testing starts from $1,000 for narrowly scoped work and rises with the surface area and the depth of the authorization model. What you should not do is buy the cheapest possible test in order to have a document. Buyers read the findings, and a report with two low-severity issues on a complex product reads as a test that did not look hard.

Vulnerability SLAs that survive contact with a real backlog

Committing to patch critical vulnerabilities within twenty-four hours is easy to write and hard to honour. Before you put a number in a contract, work out what your team can actually sustain.

Dependency scanning on a moderately sized application will produce dozens of findings in its first run, many of them in transitive dependencies of packages you did not choose, several of them in code paths you never execute. A blanket twenty-four hour commitment against that volume is a promise to fail. The workable position defines severity by exploitability in your context rather than by the raw score, states the remediation window per severity, allows for a documented risk acceptance path with an expiry date, and commits to reviewing acceptances rather than letting them accumulate silently.

Then measure the thing that actually indicates health, which is not the count of open findings but the count of findings past their own due date. A team with two hundred open lows and zero overdue items is in better shape than a team with twelve open items where six are three months late, and any reviewer who knows the work will read it that way.

When the security review goes badly mid-deal

Sooner or later a review surfaces something you cannot answer well. The instinct is to minimize it. That is the wrong move, because the analyst has almost certainly seen the same gap at other vendors and knows how significant it is.

What works is a written remediation commitment with three components: an accurate statement of the current position, the compensating control that reduces the risk in the interim, and a date with a named owner. Most enterprise security teams have a formal mechanism for accepting a vendor with open items and a remediation plan, because otherwise they could not buy anything. What they cannot accept is a vendor who was vague and turned out to be wrong.

If the gap is genuinely disqualifying, ask whether a conditional path exists: a smaller initial deployment, a restricted data set, or a pilot in a non-production capacity while you close it. Deals more often shrink than die at this stage, and a shrunk deal with a credible plan usually grows back at renewal.

The item most teams forget

Your own use of third-party tools is now a standard line of questioning, and it moves faster than most companies' vendor processes. Every tool your team adopted this year that touches customer data is a subprocessor, including the ones adopted on a corporate card without anyone telling you. That covers support desks, analytics, session replay, transcription services, and any assistant or model provider your engineers pointed at production data.

Session replay tools deserve particular attention, because they capture whatever is on the screen, and if your product displays regulated data then your replay vendor is now processing it. Buyers ask about this specifically. Run an inventory before you are asked, publish the list, and put a lightweight approval step in front of new tools so the list stays true.

When not to run this program yet

If you are pre-product-market fit and chasing a single large logo that found you rather than the reverse, be honest about the odds. Building the full set of controls for one speculative deal has sunk more small engineering teams' quarters than any other well-intentioned initiative. Ask the prospect's security contact which items are hard gates. Build those. Defer the rest until a second buyer asks.

If your fundamentals are not in place, do not start with an audit. Multifactor authentication on every account, secrets out of source control and into a manager, backups with one tested restore, logging that would let you reconstruct an incident, and a written list of who has access to what. That work is unglamorous, costs mostly attention rather than money, and no certification is worth anything without it. A team that skips it and buys a report has purchased a document describing controls that do not function, which is a liability the first time something goes wrong.

And if you can do this yourself, do it yourself. Plenty of engineering teams with a capable lead and a bit of runway get through their first assessment without outside help, and we would rather tell you that on a call than sell you a program you do not need. Where we are worth paying for is when the work is blocking revenue and nobody internally has the time or the scar tissue, which is the situation our compliance work and ongoing engagements exist to handle. If you want a straight opinion on which of those you are, tell us what your buyer is asking for.

Running the questionnaire itself is a separate discipline

The checklist tells you what to build. It does not tell you how to survive the administrative load that arrives once you are selling to several enterprises at once. A 300-question assessment takes a competent person between six and twenty hours the first time, and most of the second one is the same content in a different spreadsheet layout.

Build an answer library early. One document, one owner, every answer written once with the supporting evidence named beside it: the policy file, the scan output, the configuration screenshot. Date it, because the failure mode is not a missing answer, it is an answer that was true in March. When the standardized formats arrive, SIG Lite or the Cloud Security Alliance CAIQ, you transcribe from the library rather than re-deciding what you believe about key rotation at eleven at night.

A published trust page shortens the exchange. Put the subprocessor list, the uptime history, the vulnerability disclosure address, and current certifications where an analyst can find them without emailing you. Keep the SOC 2 report behind a request form and an NDA, since it contains architecture detail you should not scatter. Teams that do this see questionnaires shrink to the questions genuinely specific to their product. We keep client evidence in a free traztech Workspace for the same reason: artefacts are easier to defend when they live in one place with a date on them.

The contract terms that arrive after the questionnaire

Passing the security review moves you to legal, and the security exhibit attached to an enterprise master services agreement is where founders sign commitments nobody in engineering has read. Three clauses cause most of the trouble.

Breach notification windows are frequently drafted at twenty-four hours from discovery, and sometimes from occurrence, which is a different and much worse commitment because you cannot notify about something you have not detected. Negotiate to discovery, and make sure your logging would let you discover it.

Audit rights often include the buyer's right to inspect your facilities on notice, which is cheap to grant once and expensive if fifty customers exercise it. The standard counter is that a current SOC 2 Type II report satisfies the right, with on-site inspection reserved for the period after a material incident.

Security-related liability is regularly carved out of the general cap. Check it against your cyber insurance limit, because a carve-out above your coverage is an uninsured exposure on the balance sheet. Buyers will also ask for a certificate of insurance naming a limit, so get that in place before the redline arrives rather than during it.

What drives the cost, and when the cheaper answer wins

The predictable spend is the audit, the testing, and the engineering time to close gaps. The unpredictable spend is rework: evidence in a format the auditor rejects, a test scoped too narrowly for the buyer, a policy set that describes a company you are not. On one engagement the audit firm reduced its own quote by $11,000 once the readiness position was documented, which is written up in our auditor vetting case study. Our fixed-scope work is listed on the pricing page so you can see the floors before you talk to anyone.

The cheaper answer is right more often than a consultancy will tell you. If one buyer wants SSO and encryption evidence and nobody has asked for a report, do not buy an audit. If your product does not hold regulated data yet, a well-scoped test of the authorization model beats a broad assessment that produces paper. Bring in outside help when the work is blocking revenue and no internal owner exists, not because a checklist made you anxious.