A proxy vendor security questionnaire should cover what a standard SaaS template misses: how the vendor protects credentials that route traffic in your name, what it logs about your requests and for how long, who else touches that data, and whether its assurance reports are issued or still in progress. The questionnaire below has 40 numbered questions in seven sections, each with a note on what a good answer looks like. Copy the questions into your template, send them as written, and use the notes to score the replies.
How to use this questionnaire
Send the proxy vendor security questionnaire as a block and ask for answers inline, with documents attached or offered under NDA. Ask for specific numbers, dates and document names rather than yes or no; "yes" to "do you encrypt data at rest" tells you very little, while the named mechanism and scope tells you a lot.
If your organization already uses a standard questionnaire such as the Shared Assessments SIG Lite or the Cloud Security Alliance's CAIQ, you do not need to replace it. The sections below map onto the familiar domains of those frameworks: identity and access management, logging and monitoring, third-party management, cryptography, incident management, threat and vulnerability management, assurance, and business continuity. Send your standard set and attach this one as a proxy-specific supplement. The proxy-specific questions, particularly on traffic metadata and sub-processors that carry traffic, are the ones a generic template will not ask.
This questionnaire covers security. Sourcing and procurement questions are in the proxy provider due diligence checklist, and the contractual side of data protection is in what a proxy provider DPA should cover.
Access control and credential handling
Proxy credentials are bearer tokens for your spend and your traffic. The vendor's handling of them, and the controls it gives you, matter more here than in most vendor reviews. How IP allowlisting compares with username and password authentication covers the customer-side choice.
Which authentication methods do you support for proxy connections?
Good answer: at least username and password and IP allowlisting, with the ability to use allowlisting alone where you want no credential in transit.
How are proxy credentials stored on your side, and can your staff read them?
Good answer: stored hashed or encrypted, not retrievable in plaintext by support staff, and shown to the customer in full only at issue.
Can we issue separate credentials per team, project or environment, and revoke one without affecting the others?
Good answer: yes, through separate credentials per team or scoped roles, with revocation taking effect in minutes.
Which roles exist in the customer dashboard, and can we restrict who sees billing, credentials and usage?
Good answer: named roles with scoped permissions, and single sign-on or multi-factor authentication for dashboard users.
How is access for your own staff to production systems granted, reviewed and removed?
Good answer: least privilege, multi-factor authentication, a periodic access review with a stated frequency, and removal on leaving tied to the HR process.
Are administrative actions on customer accounts logged, and can we see that log for our account?
Good answer: logged centrally and retained; ideally visible to the customer as an audit trail.
Logging and retention of traffic metadata
This is the section a proxy review cannot skip. The vendor sees the destination of every request you route, and that metadata can reveal your targets, your volumes and your business.
Which fields do you record for each proxied connection?
Good answer: an explicit list, typically source and exit addresses, timestamps, destination hostname, byte counts and account identifiers, with no ambiguity.
Do you inspect, parse or store the content of requests or responses?
Good answer: no, with the exception of anything the customer explicitly configures. HTTPS through a proxy is tunneled, so a vendor that claims to see content in HTTPS traffic needs to explain how.
How long is traffic metadata retained, and how is deletion enforced?
Good answer: a stated number of days, deleted automatically rather than by manual cleanup, and the same figure as in the DPA.
Who inside your company can query traffic metadata, and is that access logged?
Good answer: a small named function, such as abuse handling and billing, with access logged and reviewed.
Under what circumstances would you share our traffic metadata with a third party?
Good answer: valid legal process, with customer notification where lawful, and a published process for law-enforcement requests.
Can we obtain our own usage records for reconciliation or investigation?
Good answer: yes, through the dashboard or an export, within the retention window.
Sub-processors and data location
A proxy vendor's sub-processors include not only its cloud host but the networks that carry your traffic to the exit address.
Please provide your current sub-processor list with the function and location of each.
Good answer: a published, versioned list, including hosting and upstream network operators.
How much notice do you give before adding or replacing a sub-processor, and can we object?
Good answer: a stated notice period, commonly 30 days, with a right to object and a remedy if the objection cannot be resolved.
Where is customer account data and traffic metadata stored?
Good answer: named regions, and the transfer mechanism used for any transfer out of the EEA or UK.
How do you assess the security of your sub-processors?
Good answer: a documented review at onboarding and at least annually, using their assurance reports.
Encryption
Is all traffic to your dashboard and API encrypted in transit, and which TLS versions do you accept?
Good answer: TLS 1.2 or later only, with HSTS on web properties.
Which proxy protocols do you support, and how is traffic between our client and your gateway protected?
Good answer: a clear statement per protocol. HTTPS requests are end-to-end encrypted between your client and the target through the tunnel; the connection to the gateway itself is plaintext for HTTP and SOCKS5 unless the vendor offers a TLS-wrapped endpoint. The vendor should say this plainly rather than implying everything is encrypted.
How is customer data encrypted at rest, and who manages the keys?
Good answer: encryption at rest for databases and backups, with keys in a managed key service and access to keys restricted.
How are secrets used by your own systems managed?
Good answer: a secrets manager, no secrets in source control, and rotation on staff departure or suspected exposure.
Incident response and penetration testing
Do you have a documented incident response plan, and when was it last exercised?
Good answer: yes, with a tabletop or live exercise in the last 12 months.
How quickly will you notify us of a security incident affecting our data or credentials?
Good answer: a specific maximum number of hours, in the contract or DPA, to a named contact.
Have you had a security incident in the last 24 months that required customer notification?
Good answer: a direct answer. "No" is fine; "yes, here is what happened and what changed" is also fine. Evasion is not.
How do you handle abuse reports about traffic from your network, and how fast?
Good answer: a published intake, a stated acknowledgement window, and a case number.
When was your last external penetration test, what was its scope, and can we see a summary?
Good answer: within 12 months, by an independent firm, covering the dashboard, API and gateway, with a summary or letter of attestation available under NDA.
How are findings from testing and vulnerability reports tracked to closure?
Good answer: severity-based remediation targets and a tracked backlog.
Do you run a vulnerability disclosure program?
Good answer: a published contact or policy, ideally a security.txt file.
SOC 2 and ISO 27001 status
Assurance status is where a proxy vendor security questionnaire is most often answered loosely. The distinctions matter.
A SOC 2 Type I report tests whether controls were designed properly at a single date. A Type II report tests whether they operated effectively over an observation window, commonly six to twelve months. A vendor that is "in progress" on Type II has an open observation window and no report yet: nothing is certified, and nothing should be described as if it were. That is a legitimate position for a growing vendor, provided it is stated precisely.
A bridge letter is a management statement covering the gap between the end of the last report's period and today. It is useful only when a previous report exists, and it is not audited. For ISO/IEC 27001, the evidence is a certificate from an accredited certification body; check its scope, its validity dates, and the Statement of Applicability, since a certificate can cover a single office rather than the service you are buying.
What is your current SOC 2 status: no report, Type I issued, Type II in progress, or Type II issued?
Good answer: one of those, precisely, with dates.
If a report is issued, what period does it cover, which trust services criteria are in scope, and were there exceptions?
Good answer: the report itself under NDA, with the exceptions section intact.
If a report is in progress, who is the auditor, when did the observation window open, and when is the report expected?
Good answer: the audit firm named, the window dates stated, and an expected issue quarter.
If your last report ended more than three months ago, can you provide a bridge letter?
Good answer: yes, signed by management, covering the gap with a statement that no material changes occurred or listing those that did.
Do you hold ISO/IEC 27001 certification, and what is its scope?
Good answer: certificate, certification body, scope statement and validity dates; or a plain "no".
Which complementary user entity controls does your SOC 2 report expect us to operate?
Good answer: a list, so you can confirm you operate them.
Business continuity
What is your recovery time objective and recovery point objective for the gateway and dashboard?
Good answer: stated figures that have been tested, not only planned.
When did you last test failover or restore from backup?
Good answer: a date within the last 12 months and the outcome.
Is your service dependent on a single hosting region, upstream carrier or supply partner?
Good answer: an honest description of single points of failure and what mitigates them.
If you ceased trading or lost access to your network, what would happen to prepaid balances and our data?
Good answer: a documented position, and data export available on request.
How would you notify us of a change of control or ownership?
Good answer: written notice, with termination rights if the change is material.
Is your address supply subject to any regulatory action, investigation or dispute?
Good answer: a direct answer, and a commitment to notify you if that changes.
Who is our named contact for security matters, and how do we reach them out of hours?
Good answer: a named person or function and a monitored channel.
The continuity questions connect directly to the proxy provider shutdown playbook, which covers what to do if the answer to question 37 is ever tested.
How ProxyForge answers
Send us this questionnaire as written. Some of the answers you can check before you do: we support username and password or IP allowlisting on every proxy line, organization members hold owner, user or read-only roles, and traffic metadata is retained for 30 days. Our sub-processor list is published and versioned with 30 days' notice of change, and abuse reports are acknowledged within four hours with a case number.
On assurance, our SOC 2 Type II observation window is open and the report is expected in Q1 2027; until then we will say "in progress", not "certified". The sourcing and compliance page lists every document and its availability, and the contact page is where to send your proxy vendor security questionnaire.