Procurement guide
Managed CDN Partner RFP Scorecard: 10 Enterprise Evaluation Criteria
Evaluate a managed CDN as an operating and risk-management service, not only as capacity or a price per GB. Require evidence, exercises, and contract commitments.
On this page
A managed CDN partner can operate a meaningful part of a delivery control plane: configuration, monitoring, incident coordination, and access to request data. An RFP should therefore test customer journeys, recovery, security, data handling, and exit, not reward an attractive diagram or a generic uptime figure.
Overview
Outcome
Build a weighted, repeatable RFP that compares actual operating scope. A bidder cannot compensate for a missing data-handling, incident-notification, observability, or exit control with a high marketing score.
Set gates before assigning a score
Define critical journeys, risk tolerance, service hours, data categories, and current providers before inviting bids. Require each bidder to identify what is included, retained by the customer, subcontracted, usage-based, or excluded.
- Journey and risk
Identify browse, login, checkout, API, publishing, or streaming commitments.
- Non-negotiable gates
Data, incident, observability, resilience, and exit controls are required.
- Weighted score
Score documented and tested evidence, not assertions.
- Tabletop
Exercise a cache, WAF, origin, or DNS failure before selection.
A useful procurement process tests operating commitments against the buyer's real paths, not a generic reference architecture.
| Pre-score gate | Minimum evidence |
|---|---|
| Data handling | Data flow, subprocessor, retention, deletion, and support-access description |
| Incident notification | Contractual notification path, contacts, update cadence, and evidence sharing |
| Observability | Customer-visible telemetry, configuration history, and usable export path |
| Resilience | Tested origin, routing, cache-purge, and DDoS procedures relevant to scope |
| Exit | Export sample, migration runbook, transition support, and deletion process |
Use a ten-part scorecard
Score 0 as absent, 3 as evidenced baseline, and 5 as repeatedly tested and contractually committed. Require at least 3 on every gate and every heavily weighted category.
| Criterion | Weight | Evidence to request |
|---|---|---|
| Resilience and delivery architecture | 15 | Dependency map, journey health checks, capacity and recovery exercises |
| Operational ownership | 12 | RACI for changes, escalation, customer communication, and follow-up |
| Security | 12 | Access model, vulnerability process, shared-responsibility matrix |
| Observability and customer control | 10 | Live log, configuration-diff, security-event, and export demonstration |
| SLA and support model | 10 | Measurement, exclusions, severity, updates, remedies, chronic-failure rights |
| Data handling and privacy | 10 | DPA, locations, subprocessors, retention, and incident cooperation |
| Portability and neutrality | 8 | Provider constraints, exports, migration design, and incentives |
| Change and incident management | 8 | Emergency process, rollback, tabletop, and post-incident evidence |
| Onboarding | 5 | Inventory, baseline, acceptance tests, cutover and knowledge transfer |
| Commercial model and exit | 10 | Peak scenarios, overages, support fees, termination, and transition costs |
scenario=campaign-day WAF false-positive
question=who can reverse the route-specific policy, when, and with whose approval?
evidence=RACI + change record + customer update + recovery test
score=contract commitment, tested execution, and customer-visible telemetryTest service terms against failure, not averages
Model edge outage, degraded performance, a bad cache rule, origin impairment, and a security event. Ask how the SLA measures each case, what is excluded, who is notified, what remedy applies, and whether credits are the only remedy. RFC 9111 permits carefully designed stale serving for selected public content; it does not make private or transaction-critical content safe during an origin failure.
Provider neutrality is not automatically superior to a single-provider design. Score whether the bidder can make an informed architecture choice, disclose commercial incentives, operate the buyer's selected tools, and hand over a usable configuration and evidence set at exit.
Troubleshooting
RFP pitfalls
- Letting a high weighted score override a missing security, data, or exit gate.
- Comparing uptime percentages without the measurement point, exclusions, or customer journey.
- Treating independent assurance as proof that the proposed configuration is safe.
- Calling multi-CDN resilient without testing routing, cache, security, and origin behaviour.
Related guides
Authoritative references
- NIST SP 800-161r1-upd1: Cybersecurity Supply Chain Risk Management
- NIST SP 800-61 Rev. 3: Incident Response
- ENISA: Procure Secure
- RFC 9111: HTTP Caching
Turn an edge RFP into a decision record
Optimi can help define evidence, test scenarios, and ownership questions for a delivery service that matches your critical journeys.
Review your CDN RFP