A proxy vendor sits in the path of your traffic. Your scrapers, monitoring jobs and test suites send requests through its network, often with credentials attached, so before a residential proxy plan is approved, your security team will want answers in writing.
Most companies start from a standard questionnaire such as the Shared Assessments SIG or the Cloud Security Alliance’s CAIQ, a set of yes or no questions mapped to its Cloud Controls Matrix. Those cover the basics of any vendor. A proxy network raises a few questions they do not ask, mainly where the IPs come from and what the vendor can see. This checklist covers both, section by section, with what a good answer looks like.
This is general information, not legal or audit advice.
Why a proxy vendor gets its own review
Three things set proxy vendors apart from a typical SaaS supplier.
- They see your traffic. For HTTPS requests the vendor sees the hosts you connect to, timing and volume. For plain HTTP it sees the content.
- They hold credentials that can spend money. A leaked proxy password lets someone else run traffic on your account.
- The exit IPs belong to someone else. Residential and mobile IPs come from real people’s devices. How those devices joined the network is a legal and reputational question for you as well as for the vendor.
The last point is not theoretical. In May 2024 the US Department of Justice announced it had dismantled the 911 S5 botnet, a residential proxy service associated with more than 19 million unique IP addresses, built by spreading malware through VPN programs and bundled installers. In May 2025 the FBI warned that criminal proxy services were installing proxies on end-of-life home routers. In January 2026 Google’s Threat Intelligence Group described disrupting the IPIDEA network, whose exit nodes it observed being used by more than 550 threat groups, and concluded that claims of ethical sourcing “must be backed by transparent, auditable proof of user consent.”
Section 1: IP sourcing and consent
- How are residential and mobile IPs obtained: an SDK in partner apps, a bandwidth-sharing app, ISP agreements?
- Can you show the consent screen a device owner sees, and how they withdraw?
- Do you audit partner apps that carry your SDK, and what happens when one breaks the rules?
- Do you buy or resell IPs from other networks?
Good answer: a named sourcing model, a consent flow you can see, and an audit process. Red flag: “our IPs are ethically sourced” with nothing behind it. Our guide to how providers source residential IPs explains the models and what proof to expect.
Section 2: What the vendor sees and logs
- Which request data do you log: source IP, destination host, timestamps, bytes, full URLs?
- How long is each log kept, and who inside the company can access it?
- Do you inspect or modify traffic, for example by intercepting TLS?
- Will you disclose logs to third parties, and under what legal process?
Good answer: a field-by-field list with retention periods and no TLS interception. Red flag: “we log nothing” from a vendor that bills by bandwidth and destination, since it has to count something. Our piece on whether residential proxies are safe covers what a proxy can and cannot see.
Section 3: Access control and credentials
- Which authentication methods do you support: username and password, IP allowlisting, both?
- Can we create separate credentials per team, project or environment, and revoke one without affecting the rest?
- Does the dashboard support single sign-on and multi-factor authentication, with roles?
- Is there an audit log of account changes and credential resets?
Good answer: per-project credentials with their own limits, and MFA on the dashboard. Separate sub-users per team or client also make it possible to see which job used what.
Section 4: Encryption in transit
- Which TLS versions do the dashboard, API and proxy endpoints accept?
- Can the connection from our client to the proxy itself be encrypted?
Good answer: TLS 1.2 or newer, with TLS 1.3 supported. NIST’s guidance for US federal systems (SP 800-52 Rev. 2) sets that baseline, and it is a reasonable bar for any vendor.
Section 5: Audits and certifications
- Do you hold a SOC 2 report? Type 1 or Type 2, which period, and which Trust Services categories (security, availability, processing integrity, confidentiality, privacy)?
- Are you certified to ISO/IEC 27001:2022, and what is the scope?
- When was your last independent penetration test, and can we see a summary?
Good answer: a recent Type 2 report whose scope includes the proxy infrastructure, not only the billing website. A Type 1 report only says controls were designed suitably at one point in time; Type 2 adds an opinion on whether they operated effectively over a period. Red flag: a certificate whose scope excludes the systems you will use.
Section 6: Data protection and sub-processors
- Will you sign a data processing agreement? Under GDPR Article 28, a processor acts only on documented instructions and needs the controller’s prior written authorisation before engaging another processor.
- Which sub-processors do you use (hosting, logging, payments), and in which countries?
- Do you keep the record of processing activities that Article 30 requires of processors?
Good answer: a standard DPA, a published sub-processor list and a notice period for changes. For the wider GDPR picture, see our guide to residential proxies and GDPR compliance.
Section 7: Incidents and abuse
- How and how quickly will you tell us about a security incident affecting our account or data? GDPR Article 33 requires processors to notify controllers “without undue delay”, and controllers to notify the authority within 72 hours where feasible.
- How do you handle abuse reports about traffic from your network?
- Which targets and uses do you block, and do you verify customers?
Good answer: a named contact, a notification commitment in the contract, and a written acceptable use policy that is enforced. Abuse controls protect you too: every customer shares the reputation of the same IPs.
Section 8: Continuity and exit
- What uptime do you commit to, how is it measured, and what is the remedy when you miss it?
- If you stop serving us, how do we get our data and close credentials?
The questionnaire on one page
| Section | Ask for | Red flag |
|---|---|---|
| Sourcing | Consent flow, sourcing model, partner audits | ”Ethically sourced” with no evidence |
| Logging | Field list and retention per log | ”We log nothing” |
| Access | Per-project credentials, MFA, audit log | One shared password per company |
| Encryption | TLS 1.2+, 1.3 supported | Plain-text dashboard or API |
| Audits | SOC 2 Type 2 or ISO 27001 with proxy scope | Scope that excludes the network |
| Data protection | DPA, sub-processor list | No DPA for EU customers |
| Incidents | Contractual notice, abuse policy | No named security contact |
The bottom line
A proxy vendor deserves the same review as any supplier that touches your traffic, plus a few questions only proxy networks raise. Send your standard questionnaire, add the sourcing, logging and abuse sections above, and ask for evidence rather than statements. The answers will tell you more about a network than its pricing page.
Sources and references
- US Department of Justice, 911 S5 botnet dismantled (29 May 2024): justice.gov
- Google Threat Intelligence Group, disrupting the largest residential proxy network (January 2026): cloud.google.com
- FBI, Cyber Criminal Proxy Services Exploiting End of Life Routers (May 2025): ic3.gov
- Cloud Security Alliance, Cloud Controls Matrix and CAIQ: cloudsecurityalliance.org
- Shared Assessments, SIG questionnaire: sharedassessments.org
- AICPA, SOC 2 reporting: aicpa-cima.com
- ISO/IEC 27001:2022: iso.org
- GDPR, Articles 28, 30 and 33: eur-lex.europa.eu
- NIST SP 800-52 Rev. 2: csrc.nist.gov