SOC 2 Network Security Controls for On-Premise Environments

Every SOC 2 guide on network security assumes the infrastructure lives in AWS. The advice is always the same: configure security groups, enable VPC flow logs, turn on GuardDuty. Three clicks and the evidence practically collects itself.

For companies running production workloads on physical servers in a colocation facility, none of that applies. The firewalls are appliances, not abstractions. The network zones are VLANs configured on managed switches, not VPCs spun up through a console. The intrusion detection system is a dedicated box running open-source software, not a managed service billed by the hour.

This post walks through how to implement and demonstrate SOC 2 network security controls in on-premise environments, drawn from real implementations. It's part of a broader series on SOC 2 readiness for bare metal and on-prem infrastructure, alongside our guide to vulnerability scanning without cloud-native tools.

What SOC 2 Actually Requires for Network Security

The relevant controls map to a few core expectations. Understanding what the auditor is looking for makes the implementation decisions much clearer.

In cloud environments, the cloud provider handles many of these controls implicitly. In on-premise environments, each one requires deliberate architectural decisions, specific tooling, and structured evidence collection.

Perimeter Security: The Firewall as Your Primary Evidence Source

In on-premise environments, the firewall appliance is the perimeter. It's the VPN gateway, the packet filter, the NAT boundary, and frequently the first thing an auditor asks about.

Default-Deny as the Foundation

SOC 2 CC6.6 expects that available networking ports, protocols, and services are restricted. The simplest way to demonstrate this is a firewall configured with a default-deny ruleset, where traffic is blocked unless explicitly permitted by a documented rule.

A firewall rule export showing default-deny at the bottom of the chain, with specific allow rules above it, is clean and auditor-friendly evidence. It directly addresses CC6.6 without additional explanation. This is the network equivalent of the tiered scanning approach used for vulnerability management, where the evidence structure matters as much as the technical implementation.

Quarterly Firewall Reviews

A firewall configuration that was correct six months ago may have accumulated rules that are no longer needed, overly broad, or tied to decommissioned systems. SOC 2 expects periodic review of these configurations.

This quarterly review produces exactly the kind of evidence auditors trust: a timestamped export paired with a documented review process. It maps directly to what compliance platforms do automatically in cloud environments with security group change tracking.

Firewall Change Control

Every rule change outside the quarterly review cycle should go through a documented change process. In practice, this means a ticket with the justification for the change before it's implemented. The firewall appliance admin console typically logs the change itself, but the justification is the piece that demonstrates the control is operating as designed.

Network Segmentation: VLANs as Evidence

Cloud environments use VPCs and subnets to isolate workloads. On-premise environments use VLANs on managed switches to achieve the same outcome.

Zone Architecture

The key for SOC 2 is demonstrating that production systems are segregated from development and testing environments (CC6.1) and that the segregation is enforced at the network level, not just by convention.

Evidence That Works

VLAN configurations exported from managed switches (Cisco, HP, or similar) serve as primary evidence. These exports show which ports belong to which VLANs, confirming that the segregation documented in the architecture diagram is actually enforced on the hardware.

Pair the VLAN configuration with a network diagram that labels each zone and shows the traffic paths between them. Together, these two artifacts satisfy CC2.2 (architecture documentation) and CC6.1 (logical access through network segmentation) in a single evidence package.

Intrusion Detection: IDS for Network Monitoring

SOC 2 CC7.1 requires that the organization uses detection and monitoring procedures to identify anomalies. In cloud environments, this is typically GuardDuty or a similar managed service. In on-premise environments, open-source IDS platforms like Security Onion provide equivalent coverage.

Deployment Pattern

The most effective deployment for SOC 2 evidence monitors two critical traffic paths:

• Internet to Production capturing inbound traffic to public-facing services
• Management to Production capturing administrative traffic that could indicate lateral movement or unauthorized access

Security Onion runs signature-based detection using community rulesets (Suricata/Snort signatures). For most on-premise environments, the baseline rules generate useful detection coverage out of the box, though tuning is an ongoing process that improves signal-to-noise ratio over time.

Making IDS Evidence Audit-Ready

Raw IDS output is not particularly useful as SOC 2 evidence. What auditors want to see is a structured response process:

• Alert logs showing the system is generating detections (proving the control exists and is operating)
• Case records for investigated alerts with documented findings and response actions
• Suppression justifications for tuned-out alerts, demonstrating that suppressions are deliberate and documented rather than evidence of neglect

DNS Filtering: A Low-Effort, High-Evidence Control

DNS filtering is one of the easiest network security controls to implement and one of the cleanest to evidence for SOC 2. It maps to CC6.6 (restricting services) and CC7.2 (detecting potentially malicious activity).

Layered DNS Protection

A pattern that works well in on-premise environments is layered DNS filtering at two levels:

Network-level: Configure DNS resolvers on the firewall appliance and server networks to use a filtering DNS service (Cloudflare, CIRA Canadian Shield, or similar). This blocks known malicious domains at the network layer before any endpoint gets involved. Evidence is a firewall configuration export showing the DNS servers in use.

Endpoint-level: Endpoint security software (SentinelOne or similar) provides signature-based blocking of known malicious domains and URLs at the device level. This catches threats that bypass network-level DNS filtering through direct IP connections or encrypted DNS. Evidence lives in the endpoint management console.

This layered approach is simple to implement, produces clean evidence from two independent sources, and demonstrates defense-in-depth thinking that auditors appreciate.

Architecture Documentation: Diagrams as Formal Evidence

SOC 2 CC2.2 and CC2.3 require that system boundaries and architecture are documented and communicated. In on-premise environments, this means maintaining two critical diagrams.

Network architecture diagram showing physical and logical network topology: firewall appliance placement, VLANs, switch interconnections, IDS monitoring points, VPN access paths, and internet connectivity. This diagram directly supports CC6.1 and CC6.6 by making the security architecture visible.

Data flow diagram showing how sensitive data moves through the system: where it enters, where it's processed, where it's stored, and where it exits. Proper SOC 2 scoping depends on clear data flow documentation, and auditors use these diagrams to understand what's in scope and why.

These diagrams should be reviewed and updated at least annually, or whenever significant infrastructure changes occur. Version-controlled diagrams with visible revision dates provide stronger evidence than static documents with no history.

Alerting and Response: Proving Someone Is Watching

Having monitoring tools deployed is necessary but not sufficient. SOC 2 CC7.2 specifically requires that detected events are analyzed and responded to. The auditor needs to see that alerts lead to human review and, when warranted, to documented response actions.

Tiered Response Model

This tiered model directly maps to the CSOCs methodology where controls are evaluated based on the completeness and consistency of the response process, not just the existence of the monitoring tool.

Bringing It Together: The STEPP Lens

Looking at network security through the STEPP framework (Scope, Technology, Evidence, Process, People) clarifies what an effective on-premise implementation needs:

What Makes This Different From Cloud

The controls are equivalent. The evidence is different.

In a cloud environment, a security group change is logged automatically in CloudTrail, monitored by Config rules, and flagged by GuardDuty if it creates exposure. The entire chain is API-driven and evidence collection is largely automated.

In an on-premise environment, a firewall rule change is logged in the appliance's admin console, reviewed during the quarterly review cycle, and justified through a ticket. The chain is human-driven and evidence collection requires intentional process design.

Neither approach is inherently stronger. The on-premise approach requires more deliberate evidence architecture, but it can produce evidence that's equally compelling to auditors. The quarterly firewall review, in particular, often demonstrates more thorough human oversight than automated cloud monitoring, which can become background noise that nobody reviews.

Companies running on-premise infrastructure can also leverage compliance automation platforms like Secureframe, Vanta, or Drata for the controls that do have API integration points, such as endpoint management, identity providers, and HR systems. The platform won't cover firewall rules or IDS alerts, but it will cover a meaningful portion of the overall control set and centralize evidence from the controls it does reach.

What Comes Next

Network security is one domain in a broader SOC 2 readiness effort. The monitoring and detection capabilities described here feed directly into security logging and SIEM architecture, which is the next layer of the evidence stack. The vulnerability scanning companion post covers how to run tiered scanning across servers and network appliances without cloud-native tools. Access control, backup and disaster recovery, and configuration management each have their own on-premise considerations, and we're covering each domain in this series.

The consistent pattern across all of them: the security is achievable, the evidence requires intentional design, and the gap between doing good security and proving good security is smaller than it appears.

Frequently Asked Questions