The Layer 2 Gap in SOC 2, ISO 27001, and PCI-DSS: A Practical Framework for Demonstrating ARP Security Compliance

Compliance auditors are thorough professionals. They review access control matrices, examine encryption configurations, test incident response procedures, and scrutinize vendor management programs. What they rarely do — and what most compliance frameworks do not require them to do — is ask what is happening at Layer 2 of the network stack.

This is not a minor oversight. ARP-level attacks represent a well-documented class of threat that enables credential theft, session hijacking, and lateral movement within networks that are otherwise considered adequately secured. Yet organizations that have invested substantially in compliance programs covering SOC 2, ISO 27001, and PCI-DSS often emerge from those audits with no meaningful validation of their Layer 2 security posture — and no documentation demonstrating that ARP-specific controls exist at all.

This article examines why the gap exists, where ARP security can be legitimately mapped within existing compliance frameworks, and what documentation security teams need to produce in order to demonstrate adequate controls during audits.

Why Compliance Frameworks Are Silent on ARP

The absence of explicit ARP requirements in major compliance frameworks is not accidental. Frameworks like SOC 2 and ISO 27001 are deliberately written at a level of abstraction that avoids prescribing specific technical implementations. This approach allows the frameworks to remain applicable across diverse technology environments — a reasonable design choice that nonetheless produces a significant blind spot at the protocol level.

PCI-DSS is more technically prescriptive than either SOC 2 or ISO 27001, but even its most detailed requirements — particularly those in Requirement 1 (network security controls) and Requirement 10 (logging and monitoring) — do not explicitly address ARP table integrity, DAI configuration, or ARP-based attack detection. The framework's network segmentation requirements assume that segmentation is effective, but do not validate the Layer 2 controls that determine whether segmentation actually holds under adversarial conditions.

The practical consequence is that an organization can achieve full compliance with all three frameworks while operating a network that is trivially vulnerable to ARP spoofing attacks — and no auditor would be obligated to flag it.

Mapping ARP Security Into Existing Compliance Obligations

While no framework explicitly requires ARP controls, each contains provisions broad enough to encompass them when properly interpreted. The following mapping provides a starting point for organizations seeking to demonstrate comprehensive Layer 2 coverage.

SOC 2 — Common Criteria Mapping

SOC 2 audits are organized around the Trust Services Criteria. ARP security controls map most directly to the following:

CC6.1 — Logical and Physical Access Controls. This criterion requires that the entity implement logical access security measures to protect against threats from sources outside its system. ARP spoofing attacks that enable man-in-the-middle interception of authenticated sessions represent precisely this category of threat. Organizations can document DAI configuration, static ARP binding policies, and ARP monitoring rules as controls that satisfy this criterion.

CC7.2 — System Monitoring. This criterion requires that the entity monitors system components and the operation of those components for anomalies. ARP table monitoring, DHCP snooping logs, and correlation rules that detect binding changes or unsolicited reply patterns are directly responsive to this requirement. The key is ensuring that monitoring evidence is captured in a format that auditors can review — not merely that the monitoring exists.

CC6.6 — Boundary Protection. Controls that prevent unauthorized access across network boundaries — including Layer 2 boundary controls that prevent ARP-based bypass of VLAN segmentation — are relevant to this criterion. Organizations should document their VLAN architecture alongside the ARP controls that enforce it.

ISO 27001 — Annex A Control Mapping

ISO 27001's Annex A controls provide a more granular mapping target.

A.8.20 — Networks Security. This control requires that networks be secured, managed, and controlled to protect information in systems and applications. ARP security controls — including DAI, port security, and network monitoring — are directly responsive and should be documented in the organization's Statement of Applicability with explicit reference to ARP-specific implementations.

A.8.16 — Monitoring Activities. ARP-specific monitoring rules and alert procedures fit cleanly within this control's scope. Organizations should maintain documented evidence of ARP monitoring configurations, alert thresholds, and response procedures to demonstrate that monitoring activities cover Layer 2 as well as higher-layer traffic.

A.8.22 — Segregation of Networks. If network segmentation is cited as a security control — which it commonly is in ISO 27001 implementations — the organization bears an implicit obligation to demonstrate that the segmentation is effective. ARP controls that prevent VLAN hopping and cross-segment spoofing attacks are part of demonstrating that segregation functions as claimed.

PCI-DSS v4.0 — Requirement Mapping

PCI-DSS v4.0 provides the most specific mapping opportunities, particularly for organizations with cardholder data environments.

Requirement 1.3 — Network Access Controls. This requirement addresses controls that restrict inbound and outbound traffic to that which is necessary. ARP-based attacks can circumvent access controls by redirecting traffic before it reaches the enforcement point. Documenting DAI and port security configurations as controls that protect the integrity of network access enforcement is appropriate and defensible.

Requirement 10.2 — Audit Log Implementation. PCI-DSS requires logging of events that could have a security impact on the cardholder data environment. ARP binding changes on switches serving the CDE — particularly changes involving gateway MAC addresses — qualify as security-relevant events under this requirement. Organizations should configure syslog forwarding from switches to their SIEM and document ARP-specific alerting rules as part of their logging compliance evidence.

Requirement 12.3 — Risk Assessment. PCI-DSS v4.0 places increased emphasis on targeted risk analysis. ARP spoofing within or adjacent to the cardholder data environment is a documented threat that should appear explicitly in the organization's risk register. Its absence creates an auditable gap that a well-prepared assessor may flag.

Documentation Templates That Auditors Recognize

Mapping ARP controls to compliance frameworks is only useful if the documentation is presented in terms that auditors can evaluate. The following documentation components have demonstrated effectiveness in SOC 2, ISO 27001, and PCI-DSS audit contexts.

ARP Security Control Inventory. A table listing each ARP-specific control deployed (DAI, port security, DHCP snooping, ARP monitoring), the network segments to which it applies, the responsible team or individual, and the date of most recent validation. This document should be version-controlled and reviewed at a defined frequency.

ARP Monitoring Rule Documentation. For each SIEM rule or network monitoring alert that addresses ARP behavior, maintain a document describing the rule logic, the threat it detects, the alert threshold, and the escalation procedure. This provides auditors with evidence that monitoring is purposeful rather than incidental.

ARP Validation Testing Evidence. Quarterly or semi-annual testing of ARP control effectiveness — using controlled spoofing attempts in a test environment or switch configuration review against a hardening standard — produces evidence that controls are not merely configured but actively validated. Test results, including any findings and remediation actions, should be retained and available for audit review.

Risk Register Entry. A formal risk register entry for ARP-based threats, including threat description, likelihood and impact ratings, existing controls, and residual risk acceptance, demonstrates that the organization has considered Layer 2 risks through its formal risk management process.

Building Auditor Confidence in Layer 2 Controls

Auditors do not typically arrive at an engagement with deep expertise in ARP protocol behavior. When an organization presents Layer 2 security documentation, the auditor's primary evaluation criteria are whether the controls are documented, whether evidence of implementation exists, and whether the controls map plausibly to the framework criteria under review.

Security professionals who hold recognized credentials in ARP and Layer 2 network security are better positioned to articulate these mappings clearly and respond to auditor questions with precision. The ability to explain, in compliance terms, why a particular ARP monitoring rule satisfies a specific SOC 2 criterion — or why DAI configuration evidence is relevant to a PCI-DSS Requirement 1 assessment — is a specialized skill that increasingly distinguishes security teams that pass compliance audits from those that receive findings.

The regulatory gap in Layer 2 security coverage is unlikely to close quickly. Compliance frameworks evolve slowly, and the protocol-level specificity required to mandate ARP controls explicitly runs counter to the abstraction principles that make these frameworks broadly applicable. In the interim, organizations that proactively build ARP security documentation into their compliance programs are demonstrating a level of security maturity that goes beyond what auditors require — and that, in practice, is exactly the kind of evidence that builds auditor confidence and reduces audit friction over time.