CDN RFP Template: Writing Requirements That Get Meaningful Vendor Responses

I've reviewed more CDN RFPs than I can count over the last ten years, and the pattern's pretty consistent. A team spends weeks writing a 40-page request for proposal, sends it to five vendors, and gets back five responses that look almost identical. They all claim 99.99% uptime, global coverage, and "best-in-class" performance. You learn almost nothing. The problem isn't the vendors — it's that the requirements document didn't force them to get specific.

Why Vague CDN RFPs Get Useless Vendor Responses

Most CDN RFP templates I see start with the same generic checklist: "Do you have PoPs in North America, Europe, and Asia?" "Do you support HTTPS?" "What is your cache hit ratio?" Every vendor can answer yes, and they will. You're not learning how they handle your actual traffic patterns, your origin architecture, or your failure modes. I worked with a media company back in 2019 that issued a textbook vendor RFP like this and ended up picking the cheapest bidder. Three months after migration, they discovered the provider's "global network" routed half their South American traffic back through Miami, adding 80ms they hadn't tested for.

A meaningful CDN RFP doesn't ask if a vendor has a feature — it asks how that feature behaves under your conditions. Instead of "Do you support origin shield?", you should be asking "Describe your origin shield architecture when our primary origin in us-east-1 fails and traffic fails over to eu-west-1. How do you prevent thundering herd on recovery?" That kind of question can't be answered with a datasheet. It forces the vendor's solution engineers to actually engage, and you'll quickly see who has depth and who's just reselling capacity. If you're still building your overall evaluation approach, the CDN Vendor Evaluation Matrix: Scoring Providers on What Actually Matters is a solid companion for turning those answers into a score you can defend internally.

The other mistake is making the request for proposal too open-ended in the wrong places. I've seen RFPs that say "Describe your security features" and get a 20-page marketing dump. Be prescriptive about format. Tell vendors exactly how to structure their response, what data to include, and what you'll consider non-responsive. It makes comparison possible and saves your team days of trying to normalize five different document styles into one spreadsheet.

# BAD: Vague requirement (gets a generic answer)
- requirement: "Vendor must provide DDoS protection"
  vendor_response: "Yes, we offer best-in-class DDoS mitigation"

# GOOD: Specific, testable requirement (forces detail)
- id: SEC-04
  requirement: "Mitigate L7 volumetric attack of 500k RPS sustained for 10 minutes without origin impact"
  context: "Origin is AWS ALB, max 10k RPS. Must not require manual ACL changes."
  required_response_format:
    - mitigation_approach: "Describe detection + challenge method"
    - time_to_mitigation: "Seconds from detection to blocking (p95)"
    - false_positive_rate: "Provide for JS challenge / CAPTCHA modes"
    - reference_customer: "Name one customer with similar scale + contact"
  scoring: "0 = manual intervention, 5 = fully automated with <5s mitigation"

Writing Technical Requirements Vendors Can't Answer With Marketing

The heart of your requirements document should be use cases, not feature checkboxes. My rule of thumb is to write requirements from the perspective of an HTTP request. Follow it from the eyeball, through the edge, to origin and back. The HTTP Working Group Specifications are useful here for grounding your language — when you ask about cache behavior, reference RFC 9111 semantics like stale-while-revalidate, Vary, and cache revalidation rather than vendor-specific terms like "Edge Cache TTL." You'll get cleaner answers and you won't accidentally lock yourself into one provider's terminology.

For each major section — delivery, caching, security, observability, operations — give vendors the context they need and then ask for a constrained answer. Provide your current traffic profile: peak RPS, average object size, cacheability ratio, origin type, TLS requirements, and any compliance needs. Then ask them to map their solution to that profile. I always include a short section on what happens when things go wrong, because that's where the real differences show up. How do they purge? How fast does a config deployment propagate? What's the rollback procedure when a bad VCL or edge function breaks checkout?

Don't forget to tie your RFP to a real validation step. The strongest request for proposal I helped write last year included an appendix that described the upcoming proof of concept in detail — which domains, which percentage of traffic, which failure scenarios we'd test. Vendors knew their written answers would be tested live, so they didn't overpromise. If you're planning that phase, read the CDN Proof of Concept Planning: Designing a PoC That Answers Real Questions before you finalize your RFP language. It'll help you write requirements that translate directly into PoC test cases.

[Section 3.2] Cache Control & Origin Offload - Response Template

Context: 65% of requests are for ~50k images (5KB-2MB), 25% API (uncacheable),
10% HTML (cacheable 60s with SWR). Origin: Nginx + S3.

Q3.2.1 Cache Key Customization:
  Requirement: Must support custom cache key excluding specific query params
               (e.g., utm_*, fbclid) while including device-class header.
  Response must include:
    a) Configuration snippet (VCL, JSON, or UI) for this exact key
    b) Propagation time for key change to 100% of PoPs
    c) Risk of key fragmentation at scale

Q3.2.2 Stale Serving:
  Requirement: Serve stale on origin 5xx / timeout for 10 minutes per
               https://httpwg.org/specs/rfc9111.html#stale
  Response must include:
    a) How stale-while-revalidate and stale-if-error are implemented
    b) Observed revalidation behavior under origin failure (reference web.dev Articles on stale-while-revalidate)
    c) Metrics exposed to verify stale serving occurred

Locking Down Performance, SLAs, and Measurement

This is where most CDN RFPs fall apart. They'll state "99.9% availability SLA" with no definition of how availability is measured, from where, and what counts as downtime. Does a 30-second blip in one PoP count? Is it measured by the vendor's own monitoring or by a neutral third party like Catchpoint or ThousandEyes? I've had vendors tell me their SLA credit process requires me to open a ticket within 48 hours with log evidence — which practically means you'll never claim it. Put the measurement method in the requirements document itself.

You also need to separate marketing performance from your performance. Ask for p50, p95, and p99 Time to First Byte and full page load metrics from their Real User Monitoring, filtered to your vertical and regions — not their global average. The web.dev Articles on Core Web Vitals and TTFB give you a good baseline for what to ask for and how to interpret it. And don't accept "we have 300+ PoPs" as a performance answer. Ask for a latency map for your top 10 metros under your expected traffic load. A vendor with 50 well-connected, well-peered PoPs will often beat one with 300 thinly deployed ones.

Finally, make your table of targets enforceable. Tie each metric to a reporting obligation, a testing method during PoC and post-launch, and a clear remedy. This links your RFP directly to your migration plan and contract. The Comprehensive CDN Migration Checklist: Every Step from Planning to Cutover has a helpful section on how to carry these SLA definitions from RFP into cutover runbooks, so your ops team isn't scrambling to define "success" the night before DNS flips.

From Requirements to Reality: Structuring the Pilot and Migration Plan

Here's where most RFPs fall apart — you've got tight technical requirements, but no mechanism to verify them before you sign. Don't let vendors self-certify. Your RFP needs to mandate a live pilot with your actual traffic and your real origin, not a synthetic demo on their idealized test domain. We've seen too many clients get burned by a vendor who aced the lab test at 45ms p95, then hit 180ms in production because their PoP density in Southeast Asia was two racks in Singapore.

The language has to be explicit. Require a 14-21 day pilot on 5-10% of production traffic, load-balanced via weighted DNS or a small edge routing rule. Define dual-running requirements: both CDNs serving simultaneously, with real-time log comparison. And crucially, specify your CDN Pilot Testing Methodology: Metrics, Duration, and Success Criteria directly in the RFP — including p50/p95/p99 TTFB by region, cache hit ratio, origin offload percentage, and purge propagation time. If you don't lock this in pre-contract, you'll never get a vendor to agree to it post-signature when you have no leverage.

Your RFP should also force the vendor to detail their CDN Traffic Cutover Strategy: Migrating Without Downtime or Data Loss and DNS dependencies. Ask them: What's your recommended TTL strategy 48 hours before cutover? How do you handle stale cache during origin switch? Do you support dual-CDN active-active during migration? A serious vendor will give you a runbook with rollback thresholds — e.g., "auto-rollback if error rate exceeds 0.5% for 3 minutes or p95 latency degrades by >30%." A vague answer here is a massive red flag.

// Example: Enforceable RFP Scoring & Pilot Success Criteria (include this in Appendix A)
// Vendors must self-score and provide evidence logs for each metric

{
  "evaluation_weights": {
    "performance_p95_ttfb": 25,
    "cache_hit_ratio_origin_offload": 20,
    "purge_invalidation_p99": 15,
    "reliability_sla_credits": 15,
    "support_escalation_model": 15,
    "pricing_transparency_no_hidden_fees": 10
  },
  "mandatory_pilot_criteria": {
    "duration_days": 14,
    "traffic_percent": 10,
    "regions_tested": ["us-east", "eu-central", "ap-southeast", "sa-east"],
    "pass_thresholds": {
      "p95_ttfb_ms_max": 120,
      "p99_ttfb_ms_max": 250,
      "cache_hit_ratio_min_percent": 92.0,
      "origin_offload_min_percent": 95.5,
      "purge_global_propagation_p99_seconds": 5,
      "log_delivery_delay_max_seconds": 60
    },
    "failure_clause": "Failure to meet 3+ thresholds = no-cost pilot extension or disqualification"
  }
}

Advanced Patterns: Catching Evasions, Hidden Costs, and Architectural Mismatches

Once you've forced specifics, you'll start seeing where vendors hedge. The most common dodge is on log delivery and observability. They'll promise "real-time logs" but bury the fact that it's sampled at 10:1 or delayed by 15 minutes. Your RFP needs to pin this down: Require raw, unsampled logs delivered to your S3/GCS bucket within 60 seconds, with <1% loss, and ask for the price per million log lines. Same trick with origin shield — some vendors quote cheap edge bandwidth then charge 3x for shield-to-origin fetches. We've audited bills where shield fees were 42% of the total invoice, completely undisclosed in the RFP response.

Another pattern to troubleshoot is the "enterprise support" bait-and-switch. Every RFP response says "15-minute P1 response, dedicated TAM, Slack channel." Push harder: Ask for the last three P1 post-mortems, average time-to-resolution for your traffic profile (not their global average), and whether that TAM is shared across 30 accounts. Demand that support SLAs have teeth — 10% service credits for missing a P1 response, escalation to VP of Ops within 60 minutes. If they won't put credits behind their support SLA, they don't believe in it either.

Finally, don't forget the DNS layer. If your migration involves changing authoritative DNS or CNAME flattening, your CDN DNS Migration Planning: Changing DNS Providers Without Breaking Resolution will make or break the cutover. Require the vendor to document CNAME chain depth, support for apex domain (ANAME/ALIAS), DNSSEC compatibility, and TTL minimums. A vendor that can't answer "What's your maximum CNAME chain length before lookup latency exceeds 25ms?" hasn't thought through enterprise DNS at scale — and you'll be the one debugging NXDOMAIN spikes at 2 AM.

Frequently Asked Questions