A procurement team asks a proxy vendor one question: "Do you keep logs?" The answer comes back as a single word: "No." The deal moves forward, legal signs the DPA, and eighteen months later a regulator, a customer security questionnaire, or an incident response investigation asks a harder version of the same question. What exactly was recorded, where was it stored, for how long, and who could read it?
At that point "no logs" turns out to have meant "we do not log request payloads." Byte counters, authentication events, connection metadata, and support ticket attachments were all still there, some of them for a year, some of them in a third-party observability platform in another jurisdiction.
This is not usually vendor dishonesty. It is vocabulary drift. "No log" started as a consumer VPN marketing phrase and got imported wholesale into business-grade proxy sales without anyone defining the terms. For enterprise buyers running scraping, ad verification, or multi-account automation at scale, that ambiguity is a real compliance exposure. This article breaks down what a proxy network can technically record, what it must record to function, and how to write procurement questions that produce answers you can actually rely on.
The Two Planes: Control Plane vs Data Plane
Every proxy platform has two distinct telemetry surfaces, and conflating them is where most confusion starts.
The control plane is the account layer: your dashboard, your API keys, your sub-user structure, your billing records, your session configuration. It is inherently stateful. If a provider can show you a usage graph, generate an invoice, or enforce a sub-user bandwidth cap, it is retaining control plane data. No credible provider claims otherwise.
The data plane is the traffic path: the connection from your client to the entry gateway, the routing decision, the exit node, the target server. This is where "no logs" claims are meant to apply. It is also where the technical detail matters most, because the data plane produces several very different categories of record.
What a proxy can technically observe
Connection metadata. Source IP of your client, timestamp, duration, entry gateway, chosen exit node, bytes in and out. This is the proxy equivalent of netflow. It exists transiently in memory on every gateway by definition. The question is never whether it exists, but whether it is written to disk, shipped to a central store, and retained.
Destination information. For an HTTP CONNECT tunnel, the gateway sees the target hostname and port in the CONNECT line even when the payload is encrypted. For plain HTTP forward proxying, it sees the full request line, headers, and cookies. This distinction is significant: a provider can honestly say it never inspects encrypted traffic while still having every hostname you touched available in a gateway access log.
DNS resolution. If the proxy resolves hostnames on your behalf, its resolvers see your target domains. Whether those queries are logged, and whether resolution happens at the entry gateway or the exit node, changes both the privacy profile and the geo-accuracy of your requests.
Authentication events. User:pass logins and IP whitelist matches both generate events. Whitelisting reduces credential exposure but ties your corporate egress IP to the account in a durable way. User:pass avoids that binding but means credentials pass through more systems, including error logs when something misfires.
Payload. Full request and response bodies. Any provider retaining this at scale for customer traffic would be an outlier and a serious risk. This is the one category most buyers assume "no logs" refers to, and it is the least interesting one because almost nobody keeps it.
Operational and error telemetry. Crash dumps, 5xx traces, rate limit counters, anti-abuse signals. These are the sleeper category. A stack trace can contain a full URL with query parameters. An abuse investigation record can contain everything about a session.
Why Absolute Zero Logging Is Not a Real Product
A proxy network that recorded nothing at all could not bill you, could not enforce concurrency limits, could not investigate a compromised account, and could not respond to a legitimate abuse complaint about traffic that exited through a residential peer's connection. It also could not tell you why your success rate dropped last Tuesday.
So the honest framing is not zero logging. It is data minimisation with defined retention, which is exactly what GDPR Article 5(1)(c) actually requires. The mature version of a no-log posture looks like this:
- Byte counters aggregated per account and per sub-user, without per-request detail, retained for the billing dispute window.
- Connection metadata held in memory for session lifetime and never persisted, or persisted in truncated form for a short window measured in hours.
- Destination hostnames either not written to disk at all or written to a rolling buffer that is discarded rather than shipped to long-term storage.
- Authentication events retained for a defined security window with a documented purpose.
- No payload capture, with the exception of explicitly requested debugging sessions that the customer opts into.
Ask a vendor to describe their posture in those terms. A provider with real engineering discipline will answer specifically. A provider selling a slogan will restate the slogan.
The Compliance Layer Enterprise Buyers Actually Need to Map
Who is the controller, and of what?
This is the question most DPAs handle badly. When you route scraping traffic through a proxy, there are two separate personal data flows.
First, the data you collect from target sites. If it contains personal data, you are the controller. The proxy provider is not deciding what you collect or why, so it is generally a processor or, in some architectures, merely a conduit.
Second, the connection metadata about your own use of the service. The provider is the controller for that, because it determines the purpose and retention. Your DPA needs to acknowledge both flows, because a document that only covers the first leaves the second undefined.
Third, and often ignored entirely, there is the personal data of the peers whose devices form a residential pool. That is squarely the provider's responsibility, and it is where ethical sourcing and logging policy intersect. A network that logs heavily on the exit side is retaining data about consenting peers as well as about you.
Retention, residency, and subprocessors
A no-log claim is meaningless if telemetry is forwarded to third-party platforms. Observability stacks, log aggregators, error tracking services, CDN providers in front of the dashboard, and payment processors are all subprocessors. Each one is a place where data lives under someone else's retention policy and in someone else's jurisdiction.
Ask for the subprocessor list. Ask specifically whether gateway telemetry leaves the provider's own infrastructure. Ask where the control plane database is hosted and whether transfers outside the EEA rely on standard contractual clauses or an adequacy decision. For regulated buyers, ask whether entry gateways can be pinned to a region so traffic metadata does not transit jurisdictions your risk team objects to.
Lawful access and jurisdiction
A provider cannot hand over what it does not hold. That is the entire practical value of minimisation, and it is a stronger guarantee than any contractual promise, because contracts yield to court orders and retained data does not un-retain itself.
But jurisdiction still shapes what can be compelled going forward. A lawful order can require prospective collection even where historical logs do not exist. Mature vendors publish transparency reporting or at least describe their process for handling requests: who reviews them, whether they notify affected customers where legally permitted, and what they have actually produced. Vague answers here are a signal.
Independent assurance
Self-attestation is the weakest form of evidence. Stronger signals include SOC 2 Type II reports scoped to include logging and retention controls, ISO 27001 certification with a statement of applicability you can read, and third-party penetration test summaries. Best of all is a targeted audit of the logging claim specifically, where an assessor reviews gateway configuration and confirms that the pipeline does what the marketing page says.
Common Mistakes Buyers Make
Treating no-log as anonymity from the target. Provider logging policy has nothing to do with whether a target site fingerprints you. TLS fingerprints, header order, timezone mismatches, and IP reputation determine that. A perfectly minimised proxy will still get you blocked if your fingerprint is inconsistent.
Ignoring your own logs. Most enterprise data leakage in scraping operations happens on the customer side: proxy credentials in CI environment variables, full request URLs in application logs, response bodies cached in a debug bucket that nobody cleaned up. Audit your side before interrogating the vendor's.
Pasting sensitive detail into support tickets. Support systems are long-retention by nature. A provider that keeps nothing on the gateway may still hold, in a helpdesk platform, the sample requests you sent to troubleshoot a 407.
Accepting "no logs" without a retention number. A policy without a stated window is not a policy. Push for hours and days, not adjectives.
Assuming pool type is irrelevant. It is not. Datacenter pools involve fewer third-party data subjects and simpler compliance narratives. Residential and mobile pools involve consenting peers, which raises the bar on both sourcing documentation and exit-side telemetry hygiene.
Where Proxies Fit In
Logging policy is not an abstract privacy preference. It is an operational constraint that shapes how you architect a data pipeline. If a provider retains destination hostnames for a year, your competitive intelligence targets are documented somewhere outside your control. If it retains nothing but aggregate byte counts, your target list stays yours, and your incident response scope shrinks accordingly.
That is why infrastructure choice belongs in the compliance conversation rather than after it. Pool diversity matters because different workloads carry different risk profiles: a public pricing crawl and a logged-in account management workflow should not share the same exit-node behaviour. Session control matters because sticky sessions with defined lifetimes let you match retention on your side to the actual duration of a task. Geo-coverage matters because routing decisions determine which jurisdictions your metadata touches at all.
This is where a provider like EnigmaProxy is useful as a worked example. Running residential, ISP, datacenter, and mobile pools side by side means a buyer can assign the lowest-exposure pool type that still clears the target, rather than forcing everything through one network. The ethically sourced proxy pools behind the residential and mobile tiers matter here too: consent documentation on the peer side is what makes an exit-node network defensible when a security reviewer asks where the IPs came from.
Billing telemetry is the one category nobody escapes, which makes pricing structure part of the logging discussion. Metered plans require per-account byte accounting by definition, so understanding how a provider's plans and usage accounting are structured tells you what minimum data set has to exist. EnigmaProxy positions itself in the professional tier on that basis: predictable accounting, business-grade reliability, and pool options that let compliance and engineering agree on a configuration instead of arguing about one.
Strategic Insights: Where This Is Heading
From claims to attestation. Enterprise security questionnaires are already moving past yes-or-no logging questions toward evidence: configuration excerpts, audit scope statements, retention schedules. Expect logging policy to become an audited control rather than a marketing line, in the same way encryption at rest did.
Cryptographic and architectural proof. Confidential computing and remote attestation are maturing to the point where a gateway can demonstrate what code it is running. Full deployment across large distributed proxy fleets is not imminent, but selective attestation for control plane components is plausible within a few years and would change the evidence conversation materially.
Regulatory pressure on peer consent. Enforcement attention on how residential IP supply is acquired keeps increasing. Networks that can produce clear consent records and clean exit-side data handling will find enterprise procurement easier. Those that cannot will lose access to regulated buyers first.
Convergence of privacy and reliability engineering. Minimising telemetry forces better architecture: stateless gateways, aggregate metrics instead of per-request traces, tighter blast radius. Teams that treat logging discipline as a design constraint tend to end up with more resilient systems, not less observable ones.
Conclusion
"No logs" is a starting point for a conversation, not an answer. The useful version of the question separates control plane from data plane, names the specific record types (connection metadata, destination hostnames, DNS queries, authentication events, payload, error telemetry), attaches a retention window to each, identifies every subprocessor that touches them, and asks for independent evidence rather than assertion.
Buyers who ask it that way get better infrastructure and a much shorter incident response scope. They also get something harder to quantify: a vendor relationship where the technical answer and the marketing answer are the same answer. That alignment is the real signal, and it is what makes providers such as EnigmaProxy worth evaluating on documented practice rather than on the number of times the phrase "no log" appears on the page.