Proxy provider SOC 2 reports: how to read one

A proxy provider SOC 2 report is an independent auditor's opinion on the design and, for Type II, the operating effectiveness of the vendor's controls over a stated period. What it is worth depends on details most readers skip: the report type, the length of the observation window, which systems are in scope, which sub-service organizations were carved out, and which exceptions the auditor found. Read those before the opinion letter. And keep in mind what no SOC 2 report covers: where the vendor's IP addresses come from.

Type I vs Type II, and the observation window

SOC 2 reports are issued by licensed CPA firms under the AICPA's attestation standards. There are two types.

• Type I tests whether controls were suitably designed and in place at a single date. It shows the vendor has written the right policies and configured the right systems. It does not show they were followed.
• Type II tests whether controls operated effectively over a period, the observation window. The auditor samples evidence from across the window: access reviews that happened, tickets that were approved, alerts that were handled.

The window length matters. Three months is the practical minimum for a first Type II; six to twelve months is common for mature programs, and an annual cycle with consecutive twelve-month windows is the steady state. A three-month window says less than a twelve-month one, because fewer quarterly and annual controls, such as access reviews and risk assessments, will have come due within it.

For a proxy provider, a Type II report is the evidence to ask for. A Type I is a reasonable interim step for a vendor early in its program, provided the vendor says when the Type II window opened and when the report is expected. The proxy vendor security questionnaire has the exact questions to send for that.

Which trust services criteria were in scope

A SOC 2 engagement is scoped against the AICPA's Trust Services Criteria. Security, the common criteria, is always included. The other four are optional:

A proxy provider SOC 2 report scoped to Security alone is legitimate, but it tells you nothing directly about availability commitments. If uptime matters to your use, and it usually does, ask whether Availability is planned for the next period.

Does the report cover the proxy network?

This is the most important question, and it is answered in the system description section, which is written by the vendor's management and reviewed by the auditor. It defines the boundary of what was tested.

Read it for the following, by name:

• The proxy gateway: the servers that accept your connections and route them to exit addresses.
• The exit infrastructure: for ISP and datacenter lines, the hardware and networks that host the addresses; for residential and mobile, the systems that manage peers and route traffic to them.
• Authentication and credential systems: how proxy credentials and API keys are issued, stored and revoked.
• The customer dashboard and API.
• Usage metering and billing.
• Logging of traffic metadata, and the systems that store it.

A report can be accurate and still be of little use to you if its boundary is the vendor's corporate IT: employee laptops, email, the HR system and the company's office network. That report shows a well-run office. It does not show that the gateway carrying your traffic is patched, monitored and access-controlled. If the system description does not name the proxy service, ask the vendor in writing what is and is not covered.

Carve-outs, inclusive sub-service organizations and user entity controls

Every proxy provider depends on others: a cloud host, colocation facilities, upstream carriers, perhaps an identity verification provider. The report handles these in one of two ways.

Carve-out method. The sub-service organization's controls are excluded from the audit. The report lists them, along with complementary subservice organization controls (CSOCs), the controls the vendor assumes that party operates. To rely on the report you then need the sub-service organization's own assurance, usually its SOC 2, and you need to know the vendor reviews it. Carve-outs are normal for large cloud providers.

Inclusive method. The sub-service organization's relevant controls are tested within this report. That is rarer and more complete evidence.

Either is acceptable. What matters is that you know which parts of the service were tested by this auditor, which by another, and which by nobody. Compare the carved-out list with the vendor's published sub-processor list; a sub-processor that carries traffic and appears in neither place is a gap to ask about.

Complementary user entity controls (CUECs) are controls the report assumes you, the customer, operate. For a proxy provider they typically include protecting your proxy credentials, restricting dashboard access to authorized staff, removing departing users promptly, and using IP allowlisting where appropriate. If you do not operate them, the vendor's controls do not fully achieve their objectives for your account. List them and assign an owner. IP allowlisting vs username and password authentication is relevant to several of them.

Exceptions, management responses and bridge letters

In a Type II report, the auditor lists each control tested, the test performed and the result. An exception means the test found a deviation: an access review that was not completed, a change deployed without approval, a terminated employee whose access remained for weeks.

Exceptions are common and not automatically disqualifying. Read each one for:

• What control failed, and whether it affects the proxy service or only corporate systems.
• How many instances out of how many sampled.
• The management response, where the vendor explains the cause and remediation. A specific response with a date is reassuring; a generic one is not.
• Whether it recurs from the previous year's report.

Then read the opinion. An unqualified opinion means the auditor concluded the controls met the criteria despite any exceptions noted. A qualified opinion means one or more criteria were not met, which warrants a direct conversation with the vendor.

A bridge letter covers the gap between the end of the report's period and today. It is a management assertion, not audited, stating that no material changes occurred to the control environment or listing those that did. Ask for one when the report period ended more than about three months ago. A bridge letter only bridges from an existing report; a vendor with no issued report has nothing to bridge.

What SOC 2 does not tell you about a proxy provider

SOC 2 is designed for service organizations in general. It tests the controls a vendor chose to put in scope against general criteria. It does not ask the questions that are specific to proxy networks.

• IP sourcing. Nothing in the Trust Services Criteria asks whether residential peers consented, whether ISP addresses are leased, or whether supply was bought from a network built on compromised devices. A network could have a clean SOC 2 report and a supply chain that would not survive a sampling audit. Sourcing needs its own evidence; how to verify a proxy provider's IP sourcing sets out the method.
• Customer screening. Whether the vendor screens who else is on the network is outside most SOC 2 scopes. Proxy provider KYC covers what to expect.
• Performance. Availability controls are not a success rate. A report can cover Availability and tell you nothing about block rates on your targets.
• Legal compliance. SOC 2 is not a GDPR assessment. The DPA and transfer mechanism still need their own review.

ISO/IEC 27001 is a common alternative, particularly for vendors based in Europe. It certifies an information security management system against the ISO/IEC 27001 standard, through an accredited certification body. It carries the same scope problem as SOC 2: check the certificate's scope statement and the Statement of Applicability to confirm the proxy service, not just an office, is covered. A certificate does not include the detailed test results a SOC 2 Type II report does, so it answers "is there a managed security program" more than "did these controls work last quarter". Neither addresses sourcing.

A procedure for reading a proxy provider SOC 2 report

1. Confirm the report type, the period covered, and the audit firm.
2. Read the system description. Confirm the gateway, exit infrastructure, credentials, dashboard and metadata logging are in scope.
3. Note which Trust Services Criteria were included and ask about any missing criterion you care about.
4. List carved-out sub-service organizations and their CSOCs; obtain their reports or confirm the vendor reviews them.
5. List the CUECs and assign an owner on your side for each.
6. Read every exception and its management response; note recurrences.
7. Read the opinion; escalate any qualification.
8. Request a bridge letter if the period ended more than about three months ago.
9. Record what the report does not cover, sourcing first, and collect that evidence separately.

ProxyForge's SOC 2 status

ProxyForge's SOC 2 Type II engagement is in progress: the observation window is open and the report is expected in Q1 2027. We do not have an issued report yet, and we will not describe ourselves as certified. When the report is issued it will be available to customers and prospects under NDA.

In the meantime, the evidence a buyer can review covers the questions SOC 2 does not. The sourcing page sets out our public supply-chain policy and the twice-yearly independent sourcing audit, whose attestation is available under NDA. The data processing agreement, with EU SCCs and the UK addendum, is available before you sign, alongside a published sub-processor list. If you are running a formal review, send your questions through the contact page.