A proxy provider RFP should make every vendor answer the same questions, in the same format, against your own workload, so that the answers can be scored rather than admired. The template below covers background and scope, mandatory and scored requirements, sourcing evidence, security, data protection, SLA, support, pricing, migration and exit, and references. It ends with a weighted scoring matrix and an evaluation timeline built around a paid pilot. Copy it into your procurement document and replace the bracketed fields.
How to use this template
An RFP for proxies fails in two predictable ways. Either it is a generic software RFP with "proxy" substituted in, which never asks where the addresses come from, or it asks for everything and receives marketing copy in return. This proxy provider RFP avoids both by splitting requirements into two kinds:
- Mandatory requirements are pass or fail. A vendor that fails one is out, whatever its price. Keep this list short, or every vendor will claim to meet it.
- Scored requirements are rated 0 to 5 against the definitions in the scoring section, then weighted.
The RFP is not the whole review. It should reference two attachments rather than restate them: the proxy provider due diligence checklist for procurement and vendor risk, and the proxy vendor security questionnaire for the security team. Ask vendors to return both with their response, and score them through the relevant rows of the matrix.
Ask for evidence, not adjectives. Every scored question below asks for a document, a number or a named mechanism. A response of "yes" or "industry-leading" scores zero.
Background and scope
This is the part vendors use to price and to decide how much effort to put in. The more precise it is, the more comparable the quotes will be. Fill in the table per proxy line, even for lines you are only considering.
About us. [Company] is a [sector] company. We use proxies for [use cases, for example price monitoring, search result tracking, ad verification]. Our current provider arrangement is [single vendor / multiple vendors / none], and this RFP seeks [a primary vendor / a second source / a replacement].
Workloads and volumes.
Line Expected monthly volume Geographies Session needs Peak concurrency Residential [GB per month] [countries, any city or region needs] [rotating per request / sticky, minimum duration] [concurrent sessions] Mobile [GB per month] [countries, carriers if required] [rotating / sticky, minimum duration] [concurrent sessions] ISP (static) [number of addresses] [countries] [dedicated to us: yes / no] [requests per second per address] Datacenter [number of addresses] [countries] [dedicated to us: yes / no] [requests per second per address] Protocols and authentication. We require [HTTP / HTTPS / SOCKS5] and [username and password / IP allowlisting].
Target categories. [E-commerce product pages, search engines, travel, social platforms, and so on.] We will share named targets under NDA.
Growth. We expect volume to [grow by X% / stay flat] over 12 months.
Timeline. Responses are due [date]. See the evaluation timeline below.
State session needs precisely. "Sticky sessions" means nothing without a duration, and the difference between per-request rotation and sticky sessions changes which vendors can serve you. Rotating vs sticky proxies covers how to decide what to ask for.
Mandatory requirements
Each item is pass or fail. Ask the vendor to confirm each and attach the evidence named.
- M1 Sourcing policy. A public, versioned supply-chain policy naming permitted and prohibited acquisition channels. Evidence: the URL and current version.
- M2 Independent sourcing evidence. An independent attestation or audit of address sourcing dated within the last 12 months, available under NDA. Evidence: scope and date of the most recent report.
- M3 Customer screening. Sanctions screening of customers at signup and on a continuing basis, and a published acceptable use policy. Evidence: policy URL and a description of the screening.
- M4 Data protection terms. A DPA available for review before contract signature, with a transfer mechanism for EU and UK data where relevant. Evidence: the DPA.
- M5 Protocols and authentication. Support for the protocols and authentication methods in the scope section on every line quoted.
- M6 Pricing transparency. A written rate card for every line quoted, with no introductory rate that reverts. Evidence: the rate card.
- M7 Exit. No minimum term longer than [N] months, and a documented position on prepaid balances at termination.
- M8 Pilot. Agreement to a paid pilot at the quoted rates, on our workload, of at least [N] weeks.
M1 and M2 are there because of what happened when a top-tier residential provider was seized by federal authorities in July 2026 after its network was found to be built on compromised devices. Customers of that network had often passed a vendor review that never asked for sourcing evidence.
Scored requirements
Each question is scored 0 to 5. Keep the numbering so responses can be compared line by line.
Sourcing and provenance evidence
- S1. Describe each acquisition channel for each line quoted, and the share of supply from each.
- S2. Describe the method of your most recent sourcing attestation: who performed it, how addresses were sampled, and how each was traced to an acquisition record.
- S3. Will you trace a sample of addresses we select during the pilot to their acquisition records?
- S4. For residential and mobile supply, provide the consent disclosure shown to peers, and state how a peer withdraws and how quickly the address leaves the pool.
- S5. For datacenter and ISP supply, list the ranges or the registry objects that show who holds them.
- S6. Do you buy supply from other proxy networks or brokers? If so, name the evidence you hold for each upstream source.
Score these using the method in how to verify a proxy provider's IP sourcing.
Security
- S7. Return the attached security questionnaire in full.
- S8. State your SOC 2 or ISO/IEC 27001 status precisely: no report, in progress with dates, or issued with period and scope. How to read a proxy provider's SOC 2 report explains what to check in the answer.
- S9. Describe customer-side controls: roles in the dashboard, credential revocation, IP allowlisting, API key management.
Data protection
- S10. List every field recorded per proxied connection, and the retention period for each.
- S11. Provide your sub-processor list, the notice period for changes, and our right to object.
- S12. State where account data and traffic metadata are stored and the transfer mechanism for each transfer.
What a proxy provider DPA should cover lists the clauses to check against.
SLA and service credits
- S13. For each line, state what your SLA measures, where it is measured, over what window, and what it excludes.
- S14. State the credit formula, the cap, and whether credits are applied automatically or must be claimed.
- S15. For static addresses, state the replacement time for an address that is blocked or degraded.
- S16. State our termination rights for repeated SLA breach.
The guide to proxy SLAs explains which answers to these are worth something.
Support
- S17. Describe support channels, hours, and first response times by severity.
- S18. Will we have a named technical contact? What is the escalation path above them?
- S19. How do you notify customers of incidents and of changes to the gateway, authentication or targeting that could break an integration?
- S20. State your abuse report acknowledgement window.
Migration and exit
- S21. Describe how you would onboard us from our current provider, including whether you can match our current endpoint structure and session behavior.
- S22. Can we run your service in parallel with our incumbent before committing volume?
- S23. At termination, what happens to prepaid balances, usage records and invoices, and within what time?
References
- S24. Provide two customer references with a similar workload and volume, at least one of whom has used you for more than a year, and one former customer if available.
- S25. Provide your legal entity, jurisdiction, ultimate ownership and years trading.
Pricing format
Proxy pricing is where responses become impossible to compare unless you dictate the format. Ask for all three of the following, and reject responses that supply only a headline figure.
A flat rate card. Per-unit prices for every line quoted: per GB for residential and mobile, per address per month for ISP and datacenter. Ask the vendor to confirm the rate card is published or can be attached to the contract as a schedule.
No reverting promotions. Ask directly: "Does any price quoted revert to a higher rate after an introductory period, a first order, or a volume threshold?" An introductory rate makes the first month comparable and every later month not.
A quote against our usage profile. Give vendors the scope table and ask for the total monthly cost of that profile, itemized. This forces into the open every charge that a rate card leaves out.
Ask the vendor to itemize, with a zero where a charge does not apply:
- Per-unit price by line, and any country or region premium
- Bandwidth charges on per-address products, if any
- Setup, replacement or address-change fees
- Monthly minimums, commitments or expiry of prepaid balance
- Charges for failed requests or retries
- Price change notice period
- Payment terms: prepaid, card, invoice, and invoice terms
Per-GB and per-address prices do not compare directly, so model both against your traffic before scoring. Per-GB vs per-IP proxy pricing shows how to convert one into the other.
Scoring matrix and suggested weights
Score each scored requirement 0 to 5, average within each area, multiply by the weight, and sum. The weights below suit a buyer for whom legal exposure and production reliability both matter. Adjust them before issuing the RFP, not after reading the responses.
| Area | Questions | Suggested weight |
|---|---|---|
| Sourcing and provenance evidence | S1 to S6 | 25% |
| Pilot performance on our workload | Measured, see timeline | 20% |
| Pricing: total cost of our usage profile | Pricing section | 15% |
| Security and data protection | S7 to S12 | 15% |
| SLA and support | S13 to S20 | 10% |
| Migration and exit | S21 to S23 | 10% |
| References and vendor standing | S24 and S25 | 5% |
Use one scale for every question:
- 0: no answer, or an answer with no evidence.
- 1: a claim with no document or mechanism.
- 3: a named mechanism or document, with gaps or dependencies.
- 5: complete, specific, evidenced, and consistent with what the pilot showed.
Two rules keep the matrix honest. Have at least two people score independently and reconcile the differences in a meeting. And score pilot performance from your own measurements, not the vendor's dashboard: success rate on your targets, latency distribution, and cost per successful request. The method for that is in how to benchmark proxy providers.
Evaluation timeline, including a paid pilot
A proxy provider RFP that ends in a decision on paper is a decision on claims. The pilot, run in parallel with your incumbent, is where the score for performance and much of the score for support is earned.
| Week | Step |
|---|---|
| 0 | Issue the RFP, the due diligence checklist and the security questionnaire, under NDA |
| 1 | Deadline for vendor clarification questions; answers shared with all vendors |
| 3 | Responses due |
| 4 | Mandatory requirements screen; shortlist two or three vendors |
| 5 to 8 | Paid pilot: each shortlisted vendor runs a fixed slice of real traffic in parallel with the incumbent |
| 6 | Sourcing sample trace run on addresses observed during the pilot |
| 8 | Reference calls; security and legal review of documents |
| 9 | Independent scoring and reconciliation |
| 10 | Negotiation with the preferred vendor; contract and DPA signature |
| 11 onward | Staged ramp, with the incumbent kept warm as a second source |
Design the pilot before it starts: the same targets, the same request mix and the same time windows for every vendor, a fixed share of traffic each, and success defined by your own parser rather than an HTTP status code. Four weeks captures weekly patterns and at least one support interaction. Paying for the pilot at quoted rates matters because it tests the service and the billing you would actually receive, not a trial pool. Switching proxy providers without downtime covers how to run the parallel traffic safely.
How ProxyForge responds to an RFP
Send your proxy provider RFP to us through the contact page. The pricing section is answered from the published rate card on the pricing page, with no introductory rates that revert, and we will quote against your usage profile. The sourcing documents requested in M1, M2 and S1 to S6 are listed on the sourcing page: the public supply-chain policy, and the twice-yearly independent sourcing attestation under NDA. The DPA is available before you sign. Our SOC 2 Type II observation window is open, with the report expected in Q1 2027, and we will state it that way in S8.
For the pilot, our migration process mirrors your current endpoint structure, session syntax and authentication format on our gateway, so the parallel run compares like for like, at published rates, with no cancellation of your incumbent required.