A free VPN privacy policy does not always give one simple answer to “How long is my data kept?” Different records can follow different timelines: an IP address may be deleted when a VPN session ends, aggregated usage data may have a stated time limit, account information may remain until account deletion, and payment or fraud records may be kept longer for legal reasons.
We reviewed the privacy policies linked by 18 ongoing free-tier iOS VPN apps from a fixed U.S. App Store sample. Only two policies gave a numeric retention period for at least one data category. Ten described at least one deletion trigger, but those triggers often applied only to a particular type of data—not everything associated with the app.
Publisher disclosure: This report was produced by BearVPN, a VPN provider. BearVPN was not included in the 18-app sample or any reported percentage. The study reviews public policy disclosures and does not test backend retention, verify deletion systems, or rank product security.
Key Findings
- Only 2 of 18 app policies gave a numeric retention period for at least one data category. Both mentioned a period of up to 48 hours, but the statements applied to different kinds of usage or aggregated data—not to every category the service may process.
- 10 of 18 policies described at least one deletion trigger. Examples included the end of a VPN session, deletion of an account, or disabling an authentication-log feature.
- 12 of 18 apps were classified as Mixed. Part of the policy was specific, while another important category used general language, referred readers to a third-party policy, or gave no usable timeline.
- The 18 apps corresponded to 17 unique policy groups. Two apps used the same policy group. We report app-level results because users select apps, while also showing the deduplicated policy count as a robustness check.
These findings measure policy disclosure, not verified backend behavior or product safety.
What “Data Retention” Means in a VPN Privacy Policy
Data retention is the period or condition under which information remains available before it is deleted, anonymized, or otherwise no longer kept in identifiable form. A policy can describe that in several ways.
Numeric period
A numeric period gives a time limit, such as “up to 48 hours” or “30 days.” It is easy to understand, but it is useful only if the policy also identifies which data the number covers. A 48-hour period for usage diagnostics does not automatically apply to an email address, payment record, support ticket, or advertising identifier.
Deletion trigger
A deletion trigger ties removal to something that happens: the VPN session ends, an account is deleted, a support ticket closes, or a logging feature is disabled. This can be more practical than a general principle, although readers still need to know what is deleted and whether exceptions apply.
Purpose-based rule
A purpose-based rule says data is kept “as long as necessary,” “for as long as the account remains active,” or while it is needed to provide the service. This gives a legal or operational principle, but not always a date a user can calculate.
Not stated
“Not stated” means we did not find a usable period, deletion trigger, or general retention rule for the relevant data in the policy reviewed. It does not prove that the data is kept forever. It describes an information gap in the public document.
Figure 1. The four retention-clause types used in this study. A more specific statement for one data category does not automatically apply to every other category.
The distinction matters because a “no logs” statement usually addresses only certain VPN activity. An app may say it does not keep browsing history while still processing account, subscription, payment, diagnostic, support, fraud-prevention, or advertising data under separate rules.
The UK’s Information Commissioner’s Office explains that data protection law does not impose one universal retention period for every category. Instead, organizations should be able to justify how long they keep information and document standard periods where possible. Apple’s App Review Guidelines also require privacy policies to explain retention or deletion policies. Neither framework means every type of app data must have the same timeline.
How We Selected and Coded the 18 Apps
The sample came from a fixed U.S. App Store search for “free vpn” captured on October 12, 2026. We included apps that public information indicated had an ongoing free tier at the sampling date. This is not a market-share ranking or a random sample of every VPN available in the United States.
The 18 apps are the same ongoing free-tier subgroup used in our earlier free VPN ad disclosure study. Reusing the fixed sample makes the projects comparable, but each study asks a different question.
For this report, we followed the privacy-policy link associated with each app and coded four broad groups separately:
- VPN activity, source IP, or connection data;
- account, subscription, or payment data;
- analytics, diagnostics, support, or feedback data; and
- advertising or other third-party data.
Each category was coded as a numeric period, deletion trigger, purpose-based rule, indefinite or aggregated retention, third-party policy, not stated, not applicable, or unclear. “Not applicable” was used only when the policy said the data was not collected or retained; it is not an independent technical finding. We then assigned each app one policy disclosure level:
- Specific: at least one VPN-related category had a numeric period or deletion trigger and the policy distinguished the major data types clearly enough to interpret the statement.
- Mixed: some data received a specific explanation, but another important category was covered only by a general rule, a third-party policy, or no usable timeline.
- Generic: the policy provided only purpose-based retention language, with no numeric period or clear deletion trigger.
- Not found: the reviewed public policy did not provide a usable retention period, deletion trigger, or general retention rule.
The labels evaluate disclosure specificity, not privacy protection, security, or backend behavior.
App-level summary
The two “Yes” columns are not mutually exclusive. A policy can provide a numeric period for one data type and a deletion trigger for another. The table should not be read as a ranking from best to worst.
How This Study Differs From the iOS Privacy Label Study
Our iOS free VPN privacy-label study examined declared data categories, identity linkage, and tracking in Apple’s standardized App Privacy section. This report instead reads developer-linked policies for retention periods and deletion triggers. A label may say identifiers are collected for advertising without explaining who retains them, for how long, or under which third-party policy. The two studies therefore cannot be combined into one result.
Only Two Policies Gave a Numeric Period for Any Data Category
Two of the 18 app policies supplied a numeric period for at least one category.
X-VPN’s policy described a rolling period of up to 48 hours for certain de-identified aggregated metrics. It separately discussed account and order information. We therefore did not apply the 48-hour statement to every type of information mentioned in the policy.
PotatoVPN’s policy stated that usage data would be stored for no more than 48 hours before automatic deletion. The same policy separately described account information, billing information, application data, crash reports, aggregated data, and third-party services. Again, the 48-hour figure cannot be converted into a universal period for all of those categories.
This is why a table titled “How long each free VPN keeps your data” would be misleading. A number can be accurate for one field and inaccurate for another. It also does not mean the other 16 policies necessarily keep information longer: some described a deletion trigger, said specified VPN data was not collected, or used purpose-based language. The finding concerns numeric disclosure, not comparative retention.
Ten Policies Used at Least One Deletion Trigger
Ten of the 18 policies described at least one event that could trigger deletion or removal. The trigger was often clearer than “as long as necessary,” but it still applied only to a defined scope.
Several policies connected removal of a real or source IP address to the end of a VPN session. That statement answers a focused question about connection handling. It does not automatically answer what happens to device information, diagnostic events, aggregated statistics, subscription records, or advertising data.
Other policies used account deletion as a trigger. Deleting an account can cover profile or account records, but policies may preserve information needed for tax, accounting, chargebacks, fraud prevention, legal claims, security, or backups. The trigger therefore does not always mean every copy of every record disappears immediately.
Proton’s documentation illustrates another distinction: an option related to authentication logs belongs to account access, not VPN browsing activity. Treating an account-login log as a VPN traffic log would combine different data types and distort the policy.
Figure 2. Two overlapping disclosure indicators across the 18-app sample. Both apps with a numeric period also described a deletion trigger elsewhere in their policies.
The figure should be read as two overlapping indicators: 2 of 18 supplied at least one numeric period, while 10 of 18 supplied at least one deletion trigger. The two apps in the numeric group also described a deletion trigger elsewhere in their policies.
Most Policies Mixed Specific and General Language
The largest category was Mixed. Twelve of the 18 apps fell into this group.
Percentages are rounded separately, so the displayed shares total 100.1%. The chart uses the original counts.
Figure 3. App-level policy disclosure classifications. The categories describe specificity, not product safety or actual retention behavior.
A Mixed classification could arise in several ways. A policy might clearly say that an IP address is removed when a session ends but give only a general rule for diagnostics. It might explain account deletion but refer advertising data to outside partners. Or it might claim not to keep browsing activity while saying little about support or subscription records.
The Specific category contained one app. That does not mean the app keeps less data than every other product, nor does it establish stronger security. It means the reviewed policy connected the relevant data categories and retention language more specifically under our coding framework.
The two Generic policies provided broad purpose-based rules without a numeric period or clear deletion trigger. The three Not found policies did not yield a usable retention rule in the reviewed material. Neither label is proof of indefinite storage.
Deduplicated policy check
The 18 apps corresponded to 17 unique policy groups because VPN – Super Unlimited Proxy and VPN – Fast VPN Proxy ultimately used the same policy group. After deduplication, the distribution was one Specific, 11 Mixed, two Generic, and three Not found.
That result is close to the app-level distribution and does not change the main conclusion: most reviewed policies mixed specific and non-specific retention language. We use the 18-app count for the main result because users encounter individual app listings, but disclose the policy-level count to avoid overstating independent evidence.
One VPN Can Have Several Retention Timelines
A privacy policy can reasonably contain multiple periods because the data serves different purposes. A simplified example might look like this:
- a source IP is processed during a VPN session and removed when the session ends;
- de-identified usage metrics are kept for up to 48 hours;
- an email address remains while an account is active;
- transaction records are kept longer for tax, refund, or dispute requirements;
- a support conversation remains while the request is handled or while a legal claim is possible; and
- an advertising or analytics provider applies its own retention policy.
Each sentence can be true without producing one overall answer in days. Compressing the policy into “this VPN keeps data for 48 hours” would erase the differences between connection data, account records, and third-party processing.
Deleting identifiable information and retaining aggregated statistics are not necessarily the same event. A policy should explain what becomes de-identified and which original fields are removed; this document review cannot verify whether anonymization is technically irreversible.
What “As Long as Necessary” Does—and Does Not—Tell You
Purpose-based language is common because legal and operational needs vary. The ICO’s storage limitation guidance notes that data protection rules do not prescribe one universal period; the organization must be able to justify the time based on the processing purpose.
For a user, however, “as long as necessary” may leave several practical questions unanswered:
- Which purpose applies to each field, and when does it end?
- Is deletion automatic or request-based?
- How long do backups remain?
- Do legal, anti-abuse, or fraud records follow another schedule?
A purpose-based statement is not automatically defective or unlawful. It is simply less predictable than a numeric period or clear event. A stronger disclosure can combine both: identify the data, explain the purpose, state the ordinary period or trigger, and list the exceptions.
Third-Party Advertising and Analytics Create a Separate Retention Layer
Several policies referred to advertising, analytics, payment, attribution, or crash-reporting providers without repeating each partner’s retention schedule. A user may therefore need to identify the partner, determine what it receives, and read another policy.
We coded this as a third-party-policy category where appropriate. We did not attribute a partner’s retention period to the VPN developer unless the app policy clearly connected the partner, data, and rule. Listing a partner also does not show that it receives every user event.
Five Checks Before Relying on a Retention Claim
1. Identify the data category
Ask whether the clause applies to VPN browsing activity, source IP, connection diagnostics, account information, payment records, support messages, or advertising identifiers. A broad phrase such as “your data” may hide important distinctions.
2. Identify the type of timeline
Look for a number, an event, or only a general purpose. “Deleted when the session ends” and “kept while necessary” do not provide the same level of predictability.
3. Check the scope of a no-logs statement
A no-logs statement may cover browsing history, DNS queries, or traffic content while excluding account login records, subscription status, aggregated usage, diagnostics, or abuse-prevention data.
4. Read the exceptions
Legal obligations, taxes, payment disputes, fraud prevention, security investigations, backups, and legal claims can extend retention beyond the ordinary period. A deletion request may also require identity verification.
5. Follow third-party links when relevant
If a policy names an advertising, analytics, payment, or support provider, check what the app says it shares and whether the partner publishes a separate retention rule. Do not assume the VPN developer and the third party use the same schedule.
Limitations
This report is a public-document study, not a technical audit. BearVPN did not inspect databases, server logs, advertising SDK traffic, backups, deletion jobs, or account-erasure workflows. We cannot verify whether actual systems follow every policy statement.
The sample is limited to 18 iOS apps identified from a fixed U.S. App Store search and confirmed as having an ongoing free tier at the sampling date. It does not represent every free VPN, the full U.S. market, Android, Windows, macOS, browser extensions, or later search results.
Policies may cover several products, platforms, websites, paid plans, and corporate entities at once. Two sampled apps used the same policy group, so 18 app rows represented 17 unique policy groups.
Some policy pages did not display a date, and policies can change after our review. We record the policy URL, displayed date where available, evidence summary, and review date in the underlying coding table.
Access also differed by site. The VPN 360 product notice was available, while the linked general policy endpoint restricted automated access during review. We coded only the content we could verify and did not infer the missing fields. This does not mean VPN 360 lacks a general privacy policy.
“Not found” means no usable retention statement was found in the document reviewed. “Not applicable” reflects a policy’s statement that specified data is not collected or retained. Neither result is independent verification of backend behavior.
Finally, disclosure specificity is not the same as short retention. A policy can be very clear about a long period, or vague about a period that is short in practice. This research evaluates the disclosure, not the undisclosed implementation.
What the Evidence Supports
The reviewed policies do not support one universal answer to how long free VPNs keep data. Only two of the 18 app policies gave a numeric period for at least one category, while ten provided at least one deletion trigger. Most combined a specific statement for one type of data with broader or missing information for another.
For users, the most useful policy is not necessarily the one with the shortest number. It is the one that clearly connects each important data category to its purpose, ordinary retention period or deletion trigger, and relevant exceptions.
Data retention is also only one part of the wider question of whether free VPNs are safe. App behavior, traffic security, ownership, advertising, data collection, independent testing, and actual policy compliance require separate evidence.
Frequently Asked Questions
Some policies say they do not keep specified VPN activity while separately describing account, payment, diagnostic, support, aggregated, or advertising-related data. The answer depends on the category and policy scope.
There is no universal period. Some reviewed policies said a real or source IP was processed only for the VPN session and removed afterward. Others said they did not retain specified IP data or did not give a usable timeline. An IP statement should not be extended to unrelated account or third-party records.
Not necessarily. “No logs” often refers to browsing activity, traffic content, DNS requests, or destination history. A service may still process account authentication, subscriptions, payments, diagnostics, customer support, fraud prevention, or aggregated statistics.
It means the retention period depends on the purpose for which the data is used. The phrase does not by itself tell a reader the number of days or exact deletion trigger. A more informative policy identifies the category, purpose, ordinary trigger or period, and exceptions.
Not always. Account deletion may remove account data while certain transaction, tax, fraud-prevention, security, dispute, or backup records remain for a justified period. The policy should explain the scope and exceptions.
No. App Privacy labels summarize declared data categories, purposes, identity linkage, and tracking. They generally do not provide a complete retention schedule. The developer’s full privacy policy is the more likely place to find periods, deletion triggers, and exceptions.
Sources and Reproducibility
The app-level policy links are included in the summary table above. The evidence was coded on October 23, 2026. Selected material statements and policy-page availability were rechecked on October 27, 2026; access conditions differed by site.
The underlying evidence table records the app name, App ID, policy URL, displayed policy date, stated scope, unique-policy group, coded result for four data groups, presence of a numeric period, presence of a deletion trigger, exceptions, overall policy disclosure level, evidence summary, and review notes.
Framework references:
The study should be updated if a policy changes its scope, retention statement, linked entity, or accessibility. Corrections should identify the affected app, old coding, new evidence, and update date rather than silently replacing the result.
