Generic RFPs miss the things that actually matter for a multi-year SaaS contract. This template centres on the four risks that bite later: how your data is isolated from other tenants, what you get when you leave, what the renewal looks like in years 2 to 5, and whether the SLA has real teeth. Built around the standard 10 section RFP frame, with SaaS specific requirements bolted into each.
SaaS makes head to head comparison easy enough that most teams over use the RFP process. The lift of building a 10 section document, inviting 5 vendors, scoring 5 weighted criteria, and running 3 demos can soak 200 procurement hours. For a $30K annual contract that math does not work. The Hackett Group benchmark on procurement transaction cost puts a managed RFP at $40K to $60K of internal time loaded cost. The trigger for an RFP rather than a 2 vendor bake off should be one of five:
At $100K ARR or more, list-price negotiation alone justifies the structured process. Vendors negotiate harder against documented competition than against a sole-sourced ask. A typical 12 to 18 percent discount on a $250K ARR contract recovers the procurement labour within month one.
If the SaaS will store PHI, cardholder data, or classified information, the RFP is the audit trail your security team will be asked to produce in the next assessment. SOC 2 evidence, BAA negotiations, and data processing addenda need to be discussed in the open before signature, not after.
ERP, CRM, ITSM, and HRIS replacements touch 5 to 30 integrated systems. The integration scope is where projects fail; the RFP forces vendors to commit a written integration approach before you sign. Integration discovery during implementation costs 3x to 5x what it costs to specify in the RFP.
When more than 4 vendors are in genuine contention, head to head demos do not scale. The structured RFP rubric forces apples to apples comparison. Shortlist demos then happen with 2 to 3 vendors against a known evaluation framework.
If you intend to lock a 3 or 5 year deal in exchange for a discount, the RFP is the only forum where you can validate that the vendor will still be viable in year 4. Reference checks, financial-stability evidence, and product-roadmap commitments all sit in the proposal.
None of the above? A two-vendor bake-off with security questionnaires (use the CSA Cloud Controls Matrix or the VSA Questionnaire) and a 30 day pilot will reach the same decision in a fraction of the time. For everything above, continue.
The single biggest architecture question in a SaaS RFP is how your data sits next to every other customer's data. Three models dominate. Each comes with a cost, a control, and an audit posture. The right question is not which model the vendor uses; it is what isolation guarantees they can demonstrate, and what evidence sits behind the guarantee. The table below is the section you paste into your RFP, with the vendor response columns blank.
| Tenancy model | Typical isolation | Cost adder | When to require |
|---|---|---|---|
| Multi-tenant shared | Logical: row-level security, tenant-ID column, shared encryption keys | 0% (baseline) | Default for most B2B SaaS. Demand documented logical isolation tests and incident-response procedure for tenant data leakage. |
| Multi-tenant with per-tenant keys | Logical + crypto: each tenant has unique encryption key managed via KMS / customer-managed key | +5 to +15% | When you need to demonstrate to auditors that your data is cryptographically separable. Typical for FinServ and Healthcare. |
| Single-tenant (dedicated instance) | Physical: dedicated database, often dedicated application servers | +30 to +60% | Only when regulatory requirement (FedRAMP High, certain HIPAA covered-entity roles) or contracted classified data. Otherwise over-engineered. |
For most non regulated workloads, multi tenant shared is the right answer and demanding anything more is rejecting cost efficiency without a clear threat model to defend it. Two questions to include in the requirements block:
Vendors who answer fluently will reference AWS SaaS tenant isolation strategies or Azure multitenancy guidance. Vendors who hand-wave have not done the work.
SLAs in SaaS contracts are often theatre. The published 99.9 percent number is meaningful only if the definition of downtime is honest and the service credit is large enough to motivate the vendor to avoid an outage. Three things to specify in the RFP, then negotiate before signature.
99.9 percent monthly = 43 minutes of allowable downtime per month. 99.95 percent = 22 minutes. 99.99 percent = 4 minutes. Annual measurement (instead of monthly) lets vendors hide one bad month in the average. Demand monthly measurement. The cumulative-minutes approach is the standard in mature SaaS contracts.
Standard exclusions in vendor SLAs: scheduled maintenance, force majeure, customer fault, third-party provider outages, beta features, and (worst) any incident the vendor has not formally declared. Push back on each. Require: scheduled maintenance only within a defined off-hours window with 7-day notice; force majeure must be a genuine external event, not a cloud-provider outage in the vendor's chosen region; third-party provider outages count toward downtime if they are a documented dependency.
Default credit of 10 percent of monthly fee for a missed 99.9 percent SLA is too small to motivate reliability investment. Negotiate a stepped credit: 10 percent for first breach, 25 percent for second consecutive month, 50 percent and termination right after the third. Service credits should be calculated against the customer's invoice that month, not the platform-fee component only.
P95 page load under 2 seconds, or P95 API response under 500 ms, is more useful to your users than a 99.9 percent uptime number. A site that is technically up but takes 8 seconds per page is functionally down. Include both in the RFP.
Most SaaS contracts are silent on what happens to your data when the contract ends. Silence favours the vendor. Without an explicit clause, you may receive a partial export in a proprietary format with no schema, no deletion confirmation, and an exit assistance fee priced as if it were a bespoke consulting engagement. Six things to include in the RFP requirements, then in the master agreement.
Most vendors agree to all six once asked because they have already drafted the clauses for their enterprise customers. The difference between an enterprise contract and a mid market contract on this point is whether the buyer thought to ask. Sample clause language is in RFP Terms and Conditions.
SaaS vendors price five different ways and the comparison is not obvious. Per user is the default but the actual cost per outcome depends on how many users you really need, how the vendor counts a user (named vs concurrent vs active), and what is bundled in. The pricing section of the RFP should require vendors to disclose all of the following so you can normalise the proposals.
| Model | Pros | Cons | Negotiation lever |
|---|---|---|---|
| Per named user | Simple to model; predictable | Pay for shelfware; user count creeps | Insist on 'active user' definition; quarterly true-down |
| Per concurrent user | Fairer for shift workers and contractors | Hard to forecast peaks | Audit log of concurrency; right-size after 90 days of telemetry |
| Usage / consumption | Pay only for value delivered | Bill shock; finance can't budget | Hard cap with notification at 80% of cap |
| Platform fee + tiered modules | Modular; pay for what you turn on | Bundling games at renewal | Lock module-by-module pricing at signature for full 3-year term |
| Flat enterprise license | Unlimited use within company | High floor; only viable above ~500 users | Renewal cap (typically CPI + 3% max) |
The single most under negotiated SaaS pricing term is the renewal uplift cap. Default vendor language allows uplifts of 7 to 10 percent annually with no ceiling. By year 5 a $200K initial contract has compounded to roughly $290K assuming a 7.7 percent average. Negotiate one of: a flat cap (3 to 5 percent), a CPI linked cap (US Consumer Price Index plus 1 to 2 percent), or a renewal at the same per unit price as year one. For Gartner research on SaaS renewal economics, see the published Gartner finance research on SaaS spending.
Security questionnaires are tedious; their alternative is a 30 page survey duplicated across every vendor. The middle ground is to require a small set of recognised attestation documents plus targeted answers to specific questions your environment cares about. Mature vendors keep these on hand and turn them around in 48 hours; immature vendors do not, which itself is data.
Type II covers an observation window (typically 6 to 12 months) of how controls actually operated, not just whether they were designed. Type I is design only and is not sufficient for production SaaS. Demand the full report under NDA, not just the bridge letter or the marketing summary.
ISO 27001 certifies the design of the information security management system. Required by many EU enterprise customers and increasingly demanded for federal-sector subcontracting. Demand the certificate plus the Statement of Applicability so you can see which controls are in scope.
Most recent third party penetration test, summary letter with findings remediated. Detailed findings need not be shared in the RFP stage; the summary should confirm independence of the tester and the testing methodology (OWASP, NIST, or PTES).
SLA for patching critical vulnerabilities (typically 7 to 14 days), how the vendor identifies vulnerabilities (Snyk, Dependabot, Tenable, Qualys), and the most recent CVE the vendor patched in production. Vendors who cannot answer the last one are not patching.
Current sub-processor list, plus a Data Processing Addendum compliant with GDPR Article 28 (or your jurisdiction's equivalent). If the vendor's DPA template is older than 2023, the GDPR Standard Contractual Clauses are likely out of date.
Time from incident detection to customer notification (regulatory minimums vary: GDPR 72 hours, HIPAA 60 days, US state breach laws typically 30 to 60 days). Demand a contractual commitment, not a published policy that the vendor can change unilaterally.
The full NIST framework reference is at NIST Cybersecurity Framework and the AWS shared responsibility model at AWS Shared Responsibility Model. Reference these in the RFP requirements so vendors know the framework you are operating against.
The standard 30/25/20/15/10 weighting in the master RFP template tilts toward technical approach. For SaaS, security and total cost of ownership matter more than implementation methodology. Here is a SaaS specific weighting profile that has worked well across the procurement reviews captured in the Hackett Group benchmarks.
Reference profile only; tune for your situation. A regulated industry should push security above 30 percent. A commodity SaaS replacement (calendar, simple comms tool) should pull functional fit down and cost up. The exercise of weighting before you read proposals removes the temptation to retrofit a winning narrative to the proposal you already liked. For the full scoring mechanics see RFP Evaluation Criteria.