The B2B SaaS Enterprise-Ready Checklist: 25 Things You Need Before You Sell to a Fortune 500
The 25 specific capabilities a B2B SaaS startup needs in place before selling into enterprise — what each one is, why it matters, and how to phase the work.
The first time a B2B SaaS founder lands a real enterprise opportunity, they discover that the product they have been selling to small businesses is missing about 20 things the enterprise buyer takes for granted. The discovery is usually painful and usually happens in the middle of the deal, when the procurement team sends a 200-line questionnaire and the security team asks for documentation that does not exist.
This article is the inverse of that experience. The 25 specific capabilities I make sure are in place — or at least planned — before a startup commits to going upmarket. Some of these are technical, some are organizational, some are documentation. All of them get asked about. None of them are surprises if you have built them in advance.
I cluster them into five categories: identity and access, security and compliance, data and privacy, reliability and operations, and commercial. Five each. Twenty-five total.
Identity and access (1–5)
1. SSO via SAML or OIDC. Enterprise customers do not want to manage individual logins for your product. They want their users to log in via their identity provider (Okta, Azure AD, Google Workspace, etc.) and have access provisioned automatically. Ship at least one of SAML 2.0 or OpenID Connect.
2. SCIM provisioning. SCIM lets the customer's identity provider create, update, and deprovision users in your system automatically. Without it, every joiner and leaver at the customer requires manual work. Some customers will require it; many will strongly prefer it.
3. Role-based access control with custom roles. Out of the box you might have "admin" and "member." Enterprise customers want more granularity — read-only roles, billing-only roles, custom roles they can define themselves. Build the model that supports it even if you only ship two default roles initially.
4. Audit logs accessible to the customer. A log of "who did what when" inside the customer's account, exportable. This is for the customer's own compliance team, not yours. SIEM integration is even better but exportable JSON or CSV is the floor.
5. Session management and timeouts. Configurable session timeouts, the ability to force-log-out users, and the ability for an admin to see active sessions. Enterprise security teams ask about all of these.
Security and compliance (6–10)
6. SOC 2 Type II. The de facto requirement for any enterprise B2B SaaS. See my separate post on SOC 2 for the timeline and cost.
7. A current penetration test report. Within the last 12 months, conducted by a reputable third party, with findings remediated or in a remediation plan. Customers will ask for the report (or a redacted version).
8. A documented security program. Written policies, an incident response plan, a data classification scheme, an asset inventory, a vendor management process. The artifacts of a real security program, not just the audit certificate.
9. Encryption everywhere. Data encrypted at rest and in transit, with key management you can describe. Bring-your-own-key (BYOK) is requested by some highly regulated customers but is not table stakes for most.
10. A security questionnaire response library. A document or system where you have pre-written answers to the 100–200 most common security questions. The first time you build this is painful. The second time you reuse it, you save 20 hours.
Data and privacy (11–15)
11. Data residency options. Some customers (especially European ones) require their data to be stored in a specific geographic region. You do not need to support 12 regions on day one. You probably need to support at least two — North America and Europe — by the time you sell to a global enterprise.
12. A data processing addendum (DPA). A standard document, ready to sign, that satisfies GDPR Article 28 and equivalent regulations. Enterprise customers will ask for one before they share any personal data.
13. Data export and portability. The customer can export all of their data in a standard format (JSON, CSV, or both) at any time. This is required by GDPR and reasonable customers anyway.
14. Data deletion on request. The customer can request deletion of all their data, and you can complete the deletion within a reasonable window. Document the process and the timeline.
15. Subprocessor list and notification. A public list of every subprocessor (vendor) that processes customer data on your behalf, plus a process to notify customers when you add a new one. GDPR-derived requirement that almost every enterprise customer will check.
Reliability and operations (16–20)
16. A Service Level Agreement (SLA) you can actually commit to. 99.9% uptime is a common floor. Some enterprise customers want 99.95% or higher with credits attached. You need monitoring that proves what your actual uptime is and a process to issue credits when you miss.
17. A status page. A public page (not behind your auth) where customers can see current incidents, scheduled maintenance, and historical uptime. Statuspage, BetterStack, Instatus, or hosted equivalents.
18. Business continuity and disaster recovery plans. Documented. Tested at least once a year. Specifies RPO (recovery point objective) and RTO (recovery time objective). Enterprise risk teams ask about these specifically.
19. Backups and the ability to restore. Daily backups, encrypted, retained for at least 30 days, and a documented restore procedure that has been tested. Untested backups are not backups.
20. A real on-call rotation. Someone is on call 24/7, can respond to customer-impacting incidents within a defined window, and follows a real incident process. PagerDuty or Opsgenie or Better Stack or equivalent.
Commercial (21–25)
21. A real master services agreement (MSA). Not your generic terms of service. A negotiable contract, with redlines accepted, prepared in advance for enterprise procurement. Get a lawyer who has done this before to draft the first version.
22. Custom invoicing and payment terms. Net 30 or Net 60 instead of credit card. Annual contracts. Multi-year contracts with pricing locked in. Your billing system needs to support all of this without manual workarounds.
23. Volume pricing or per-seat tiers. Enterprise customers do not pay the same per-seat price as your SMB customers. Build the pricing model that supports tiered or negotiated pricing.
24. A real customer success function. Not a single overworked person juggling 200 customers. A named CSM for each enterprise customer, regular check-ins, a documented onboarding plan, and an escalation path.
25. A clear renewal and expansion process. Enterprise contracts renew annually. The renewal motion needs to start 90 days before the renewal date. Without a real process, you will lose contracts you should have kept.
How to phase the work
You do not need all 25 items on day one. You need a phased plan that gets you the right items at the right time.
Phase 1 — Before the first enterprise pitch. Items 1 (SSO), 6 (SOC 2 in progress), 10 (security questionnaire library), 12 (DPA), 16 (SLA), 17 (status page), 21 (MSA). These are the items that come up before a single line of code is signed.
Phase 2 — During the first enterprise sales cycle. Items 2 (SCIM), 4 (audit logs), 7 (pen test), 8 (security policies), 11 (data residency if EU is in scope), 14 (deletion), 15 (subprocessor list), 18 (BCP/DR), 19 (backups). These are the items that come up in the procurement and security review phases.
Phase 3 — Within 90 days of the first enterprise customer. Items 3 (RBAC), 5 (session management), 9 (encryption details), 13 (data export), 20 (on-call), 22 (custom invoicing), 23 (volume pricing), 24 (CS), 25 (renewal process). These are the items the customer will discover they need over the first three months and will ask you about.
If you try to ship all 25 items before your first enterprise pitch, you will burn 6 months of engineering time on capabilities that may not be needed. If you ship none of them, you will lose the deal. The phased approach gets you to "credible" with the minimum amount of pre-work.
What this list does not cover
Vertical-specific requirements. If you are selling to healthcare (HIPAA), finance (SOC 2 plus PCI plus more), government (FedRAMP), or specific regulated industries, the list above is the floor and there will be a vertical-specific overlay. Do not assume the 25 items are sufficient for any specific vertical without checking.
It also does not cover product fit. The world's most enterprise-ready product is still useless if it does not solve a real enterprise problem. Build the product first, then build the enterprise readiness around it.
The non-obvious benefit
Beyond the immediate goal of unblocking enterprise deals, working through this list has a second benefit founders do not anticipate. The discipline of building these capabilities makes the product genuinely better for everyone — including SMB customers. SSO support helps mid-market customers too. Audit logs help customers of every size. A real status page builds trust with anyone who relies on you. The work is rarely wasted.
Counterpoint: do not go upmarket too early
A warning. Going upmarket is expensive. The 25-item list represents months of work and significant engineering distraction. If your SMB business is working well and you are picking up enterprise pursuit because it sounds prestigious, reconsider. The right time to build enterprise readiness is when there is real demand pulling you upmarket, not when you are pushing because you have read too many growth articles.
The signal to go upmarket: enterprise buyers are reaching out unprompted, asking for things you cannot do, and you are saying no to deals you would like to win. The signal to wait: you are chasing enterprise customers because the SMB business is not growing fast enough.
Your next step
Print the 25 items. Go through the list with your CEO and your engineering lead together. For each one, mark green (done), yellow (partially done), or red (not done). If you have more than 10 reds, you are not ready to commit to enterprise sales — and that is information worth knowing before you put a deadline in front of a prospect.
Where I come in
Going upmarket is one of the most common reasons founders bring me in. The conversation usually starts with "we have a big deal in the pipeline and we are not sure we can support it." A typical engagement maps the 25 items, prioritizes the work, runs the security review responses, and acts as the technical voice in the customer conversations. Book a call if you have an enterprise opportunity in front of you and want help getting ready in the right order.
Related reading: SOC 2 for Seed-Stage Startups · The Startup Security Baseline · What Is a Fractional CTO
Going upmarket? Book a call before you commit a deadline.
Get in touch →