Anonymized Traffic, VPN, and Proxy Compliance: What Security Frameworks and Regulations Say

Navigating the regulatory landscape can be confusing when standards seem to both approve of and restrict some anonymizing tactics. This post explains how to balance regulatory requirements with security best practices.

Anonymized traffic from VPNs, residential proxies, and other anonymizing infrastructures raise complex compliance and monitoring questions. While most information security frameworks do not explicitly call out “anonymizers,” they do provide controls that directly govern VPN and proxy use, and in many cases consider obscured IP addresses as personally identifiable information (PII) to be protected.

This post examines key controls in common cybersecurity and regulatory frameworks, including what frameworks consider IP addresses as PII and how they allow the use of VPNs, and how to structure a governance program that balances enterprise security and regulatory compliance.

Note: The information in this post summarizes key requirements only and is not intended to be comprehensive regulatory advice. Please consult your organization’s auditor for specific guidance.

IP Addresses as PII

Before we dive into security controls and frameworks, it is important to make a clear distinction: many frameworks and regulatory regimes treat IP addresses as personally identifiable information (PII) that can impact how an organization treats deanonymized IP addresses.

NIST Frameworks

The U.S. National Institute of Standards and Technology (NIST) provides several guidelines for protecting PII – in this case related to IP addresses.

NIST SP 800-122 (Guide to Protecting the Confidentiality of Personally Identifiable Information PII) says that IP addresses can constitute PII in certain contexts. NIST SP 800-53 Rev. 5 (Security and Privacy Controls for Information Systems and Organizations) goes further with two controls related to IP addresses and PII:

• PT-4 (Minimization of PII Collected) limits unnecessary collection of IP data.
• PT-5 (Minimization of PII Retained) supports anonymization/de-identification of IP logs.

ISO Frameworks

The International Organization for Standardization (ISO) includes measures meant to protect IP addresses as PII as well, including:

• ISO/IEC 27018:2025 (Public Cloud PII) that recommends de-identification, pseudonymization, or anonymization of PII, including IP addresses in public clouds.
• ISO/IEC 27002:2022 control 8.11 (Data Masking/Anonymization) requires anonymization where feasible.

Regulatory Requirements

In addition to security frameworks, several regulatory regimes require protection of IP addresses.

• GDPR (EU): Recital 30 and Article 4 define IP addresses as personal data; Article 32 encourages pseudonymization/anonymization.
• CCPA/CPRA (California Consumer Privacy Act/California Privacy Rights Act): Civil Code §1798.140 includes IP addresses in the definition of personal information.
• HIPAA (45 CFR §164.514(b)): IP addresses are among the 18 identifiers that must be removed for de-identification in this U.S. healthcare data protection regulation.

While none of these frameworks and regulations explicitly restrict the collection and de-anonymization of IP addresses, they include provisions requiring the protection of the data – an important consideration for security, threat hunting, and fraud teams looking to leverage this data.

Legitimate VPN Use

In addition to acknowledging the requirement to protect IP addresses as PII, organizations should also understand that security frameworks allow and expect secure VPN use.

NIST SP 800-53 Rev. 5 includes several controls governing VPN usage, including:

• SC-12 (Cryptographic Key Establishment) and SC-13 (Cryptographic Protection) indicate that VPNs must use strong encryption.
• AC-17 (Remote Access) requires VPN authentication and authorization.
• AU-2 (Event Logging) says that VPN connections must be logged.

ISO/IEC 27002:2022 offers similar controls:

• 8.28 (Secure Network Services) mandates security requirements for VPNs.
• 8.24 (Use of Cryptography) requires cryptographic protection for VPN traffic.

PCI DSS v4.0 has two requirements that specifically address VPN usage:

• Req. 1.4 – firewalls must restrict access, including VPN entry points.
• Req. 12.3.10 – remote access (e.g., VPNs) must use multi-factor authentication.

Approved VPNs must be secured, logged, and controlled. Both NIST and ISO require they be secured, authorized, and monitored as part of network security architecture. Strong encryption, multi-factor authentication, and logging are mandatory.

Unauthorized VPNs, Proxies, and Obscured Traffic

Although it is clear from the regulatory guidance that VPNs are allowable, and data from obscured IP addresses should be protected, unapproved tunneling, anonymizers, and proxies are treated as security risks to be blocked or detected. Here is what the frameworks have to say:

NIST SP 800-53 Rev. 5

• SC-7 (Boundary Protection) requires monitoring and control of system communications at boundaries, which includes detecting and restricting unauthorized tunnels (VPNs, proxies, encrypted channels).
• SC-7(13) (Deny by Default / Allow by Exception) forces organizations to explicitly allow traffic types. VPN or proxy use must be authorized.
• SC-7(21) (Isolation of Information Flows) helps prevent hidden channels or routing through unauthorized paths.
• SI-4 (System Monitoring) calls for monitoring to detect anomalies, which would include unexpected use of VPNs or residential proxies.
• CA-7 (Continuous Monitoring) provides for ongoing assessment of system activity, potentially flagging obfuscated traffic.

Related to NIST 800-53, NIST SP 800-115 (Technical Testing) lists proxies, anonymizers, and tunneling as tools used by penetration testers that should be monitored.

ISO/IEC 27002:2022

• 8.16 (Monitoring Activities) requires logging and analysis of network activity, which would detect unexpected anonymization methods.
• 8.20 (Network Security Controls) requires segregation and control of networks; VPNs must be secured and managed if used.
• 8.23 (Web Filtering) and 8.24 (Use of Cryptography) imply controls to monitor and restrict unauthorized tunneling or encryption (e.g., traffic routed through residential proxies).
• 8.28 (Secure Network Services) specifically covers secure VPN use — requiring encryption, authentication, and authorization.

Related to ISO 27002, the ISO/IEC 27033 series (Network Security) goes deeper into secure VPN design and operation, including control of tunneling protocols and detection of misuse.

CIS Controls v8 Control 13.7 (Network Traffic Filtering) requires blocking of unauthorized traffic types. Additionally,

• Control 13 (Network Monitoring and Defense) calls for inspecting network traffic, detecting use of unauthorized remote access tools, and blocking anomalous outbound communications (VPNs/proxies fall here).
• Control 12 (Network Infrastructure Management) requires controlling and monitoring network devices to prevent bypass channels.

PCI DSS v4.0

• Req. 1.4/1.5 prohibits unauthorized inbound/outbound connections, with firewalls and routers restricting unauthorized traffic.
• Req. 12.10.5 says that incident response must cover detection of traffic obfuscation methods.

Under PCI, unauthorized VPNs and proxies would be considered violations of segmentation and boundary protections.

Unapproved/Unauthorized anonymizers, VPNs, and proxies are risks. All frameworks require these be blocked or monitored under boundary protection and anomaly detection controls. They should be treated as a threat vector — controls emphasize detection, prevention, and monitoring of such traffic.

Privacy Frameworks and VPN Use

Privacy frameworks, on the other hand, encourage anonymization of IP addresses (see above) but warn against anonymizers that undermine accountability.

In the GDPR, Recital 26 indicates that true anonymization falls outside the regulation’s scope, but pseudonymization does not. Article 32 provides for anonymization/ pseudonymization as a technical control.

The CCPA/CPRA (California) permits anonymization but requires transparency; anonymizers cannot conceal disclosures.

In HIPAA (U.S.), a Safe Harbor method requires removal of IP addresses. The Security Rule (45 CFR §164.312) says that VPNs are permitted for secure transport, but anonymizers that prevent logging violate auditability.

Other Sector-Specific and International Law Enforcement Guidance

Sectoral standards reinforce the point. FedRAMP, FFIEC, and others all emphasize detection, monitoring, and accountability when anonymization technologies are in play.

• FedRAMP (U.S. Cloud): Requires boundary protections and monitoring, specifically detecting unauthorized tunnels or anonymizers in cloud environments, inheriting NIST SC-7 and SI-4 controls. Inherits from NIST SP 800-53.
• FFIEC (Financial Services): IT Handbook flags VPN/proxy misuse as a penetration testing consideration. Requires monitoring for obfuscated traffic in network security guidance.
• COBIT 2019 DSS05 (Manage Security Services) and APO13 (Manage Security) mandate anomaly detection and require policies on acceptable technologies (VPNs, anonymizers).
• Budapest Convention on Cybercrime: Identifies anonymizers (VPNs, Tor) as barriers to lawful investigation; encourages interception capability.

How to Balance Enterprise Security and Regulatory Compliance for Anonymized IP Addresses

The regulatory environment governing the use of anonymized IP traffic can be confusing. In general, security frameworks such as NIST, CIS, COBIT, PCI DSS treat anonymizers as unapproved tunnels requiring monitoring, detection, and blocking. Privacy regulations such as GDPR, HIPAA, and CCPA treat anonymization as a protective measure for IP addresses but still require auditability and lawful access. Sectoral standards such as FedRAMP, FFIEC, and HIPAA) provide stricter expectations around VPNs and monitoring for obscured traffic. Finally, cybercrime conventions flag anonymizers as law enforcement challenges and encourage technical countermeasures.

The bottom line is that organizations must adopt a dual approach to de-anonymizing IP traffic that enables authorized VPNs and anonymization to protect privacy and secure remote access, while detecting and blocking unauthorized anonymizers to maintain visibility, accountability, and compliance.

How Spur Helps

Spur delivers the highest-fidelity IP intelligence available to detect anonymized, proxied, or otherwise obscured internet traffic, empowering security, threat hunting, and fraud teams to stop fake users, threats, and fraud.

Organizations leverage Spur data to investigate and enrich suspicious traffic in real-time to meet stringent security and compliance requirements found in NIST, ISO and other frameworks. Spur enables organizations to:

• Detect VPNs, residential proxies and other anonymizing infrastructure to meet the requirements of NIST SP 800-53 controls SC-7, SI-4, and CA-7, and therefore address FedRAMP compliance.
• Enrich logs to analyze network activity to meet the requirements of ISO 27002 controls 8.16, 8.20, and 8.23, FFIEC IT Handbook, and COBIT 2019.
• Act on suspicious traffic to meet the requirements in CIS Control 13, PCI requirements 1.4, 1.5, and 12, and the Budapest Convention.

The Spur approach enables teams to download and manage high-fidelity data into their own environments for sensitive IP enrichment without the risk of exposing PII to the internet to support data protection regulations as communicated in GDPR Article 32, CCPA/CPRA, and HIPAA. To get started with Spur data, sign up for a free account today.

Regulatory and Security Controls Checklists

For additional details on regulatory and security framework controls and their application to anonymized IP traffic, see the summary checklists below. The first checklist examines NIST and ISO controls, and the second provides a deeper view of the broader regulatory landscape.

Threat-to-Control Mapping for Obscured Internet Traffic: NIST 800-53 & ISO 27002

Threat / Technology	NIST SP 800-53 Rev. 5 Controls	ISO/IEC 27002:2022 Controls	Notes / Rationale
Legitimate VPN (enterprise use)	SC-7 (Boundary Protection) SC-12 (Cryptographic Key Establishment) SC-13 (Cryptographic Protection) AC-17 (Remote Access) AU-2 (Event Logging)	8.20 (Network Security Controls) 8.24 (Use of Cryptography) 8.28 (Secure Network Services)	Requires secure setup, key management, encryption, user authentication, and monitoring.
Unauthorized VPN	SC-7(13) (Deny by Default) SC-7(21) (Isolation of Information Flows) SI-4 (System Monitoring) CA-7 (Continuous Monitoring)	8.16 (Monitoring Activities) 8.20 (Network Security Controls) 8.23 (Web Filtering)	Must be detected and blocked unless explicitly approved. Monitored as anomalous traffic.
Residential Proxy / Anonymizer	SC-7 (Boundary Protection) SI-4 (System Monitoring) AU-6 (Audit Review, Analysis, and Reporting)	8.16 (Monitoring Activities) 8.20 (Network Security Controls)	These services are often used to mask identity or bypass restrictions. Treated as potential malicious outbound traffic.
Tor / Onion Routing	SC-7, SC-7(13) SI-4 IR-5 (Incident Monitoring) RA-5 (Vulnerability Scanning)	8.16 (Monitoring Activities) 8.20 (Network Security Controls) 8.23 (Web Filtering)	Should be blocked or carefully monitored due to common use in evasion and exfiltration.
Encrypted Tunnels (unauthorized SSL/TLS, SSH, tunneling apps)	SC-7 SC-8 (Transmission Confidentiality and Integrity) SI-4 CA-7	8.20 8.24 8.16	May bypass inspection tools; controls emphasize detection, inspection, and authorized use of encryption.
Traffic Obfuscation / Evasion Techniques	SC-7(9) (Restrictions on External Connections) SI-4(14) (Analyze Encrypted Traffic) AU-12 (Audit Generation)	8.16 (Monitoring Activities) 8.20 (Network Security Controls)	Requires visibility into encrypted or obfuscated flows, anomaly detection, and incident response processes.

Comparison Matrix: Treatment of Anonymizing Technologies by Framework and Regulation

Category / Framework / Regulation	Key Controls / Articles	Treatment of Anonymizing Technologies
SECURITY FRAMEWORKS
NIST SP 800-53 Rev. 5	SC-7 (Boundary Protection) SC-7(13) (Deny by Default) SI-4 (Monitoring) AC-17 (Remote Access)	Unauthorized tunnels (VPNs/proxies) treated as security risks; legitimate VPNs must be secured and monitored.
NIST CSF	Detect / Protect Functions	Anonymizers fall under Detect (anomalous events) and Protect (secure communications).
NIST SP 800-115 (Security Testing)	Section 3.4 (Testing Methods)	Lists proxies, anonymizers, tunneling as penetration tester techniques — orgs must be able to detect them.
CIS Controls v8	Control 12 (Network Infrastructure) Control 13 (Monitoring and Defense)	Requires detection and blocking of unauthorized remote access tools (VPNs/proxies).
COBIT 2019	DSS05 APO13	Policies should define acceptable use; anonymizers are managed under anomaly detection and security services.
PCI DSS v4.0	Req. 1.4, 1.5 (firewalls) Req. 12.10.5 (incident detection)	Explicitly requires restricting unauthorized tunnels; anonymizer use could violate segmentation and monitoring requirements.
ISO/IEC 27002:2022	8.16 (Monitoring) 8.20 (Network Security) 8.28 (Secure Network Services)	Secure VPNs required; monitoring for unauthorized encrypted tunnels / anonymizers.
ISO/IEC 27701 / 29100 / 29184	8.16 (Monitoring) 8.20 (Network Security) 8.28 (Secure Network Services)	Promote anonymization / pseudo-anonymization of PII (including IP addresses) as a privacy control, but anonymizers must not compromise accountability.
DATA PRIVACY FRAMEWORKS
GDPR (EU)	Recital 30 Articles 5 & 32	IP addresses are personal data. Anonymization encouraged, but anonymizers cannot prevent lawful processing/accountability.
CCPA / CPRA (California)	Recital 30 Articles 5 & 32	Treat IP addresses as personal info; anonymization acceptable but not if it hides usage / disclosure practices.
HIPAA (U.S.)	45 CFR §164.514 (Safe Harbor) Security Rule (164.312)	IP addresses must be removed for de-identification. VPNs are acceptable for secure transfer, but anonymizers must not block audit trails.
SECTOR-SPECIFIC
FedRAMP (U.S. federal cloud)	SC-7 SI-4 CA-7	Inherits NIST 800-53; requires monitoring and restricting anonymizers in cloud environments.
FFIEC (Financial Services)	FFIEC IT Handbook (Information Security)	Warns against anonymizers as evasion methods; penetration testing guidance calls for detection.
LAW ENFORCEMENT
Budapest Convention on Cybercrime	Articles on lawful interception	Identifies anonymizers as barriers to lawful investigation; promotes monitoring / interception capabilities.

Frequently Asked Questions (FAQ)