What SOC 2 Actually Requires from Your Meraki Configurations

What SOC 2 Actually Requires from Your Meraki Configurations

You’ve been told your organization needs SOC 2 Type II compliance. Your auditor sends a controls matrix. Somewhere in the spreadsheet, there are requirements about “network security controls,” “change management procedures,” and “access control policies.”

None of it tells you which specific Meraki settings to configure.

This post bridges that gap. We’ll map SOC 2 Trust Service Criteria to concrete Meraki configuration requirements — the actual settings, policies, and operational practices your auditor will evaluate.

The Trust Service Criteria That Touch Your Network

SOC 2 evaluates five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. For network infrastructure, Security and Availability carry the most weight, with Confidentiality becoming relevant when your network handles sensitive data segments.

CC6: Logical and Physical Access Controls

This is where most Meraki-specific findings occur. CC6 requires that you restrict logical access to information assets based on authorization. In your Meraki environment, this translates to several concrete requirements.

Organization admin roles must follow least privilege. Full org admins should be limited to a small number of senior network staff. Network-level admins should only have access to the networks they manage. Read-only access should be the default for monitoring personnel. Your auditor will ask for a list of all admin accounts, their permission levels, and the business justification for each.

API key management is frequently overlooked. Every API key is an admin-equivalent access credential. SOC 2 requires that API keys are inventoried, attributed to specific purposes, rotated periodically, and revoked when no longer needed. If you have API keys created by former employees still active in your org, that’s a finding.

Two-factor authentication should be enforced for all dashboard access. Meraki supports this natively, but your auditor will verify it’s mandatory (not optional) and that there are no exceptions.

CC7: System Operations — Change Management

CC7 requires that changes to infrastructure are authorized, tested, and documented. For Meraki, this means your auditor will want to see evidence of a change management process that covers network configuration modifications.

Specifically, they’ll look for: a record of every configuration change made during the audit period, attribution of each change to a specific administrator, evidence that significant changes were authorized before implementation, and the ability to demonstrate that unauthorized changes are detected and remediated.

The Meraki dashboard changelog captures some of this, but it has limitations. It doesn’t persist indefinitely, it doesn’t distinguish between authorized and unauthorized changes, and it doesn’t provide compliance-specific context. Most enterprises supplement dashboard logging with a dedicated change tracking system that provides the audit trail SOC 2 requires.

CC8: Change Management Process

Beyond tracking changes, CC8 evaluates whether your change management process is defined and followed. This includes: documented procedures for making network changes, a testing or validation step before production deployment, rollback procedures for failed changes, and post-change verification.

For Meraki environments, this means having a documented process for how configuration changes move from request to implementation. Can you show that a firewall rule change was requested, approved, implemented in a test network, validated, and then deployed to production? Can you roll back if the change causes issues?

A1: Availability Controls

If your SOC 2 report includes the Availability criteria, your auditor will evaluate whether your network infrastructure supports defined uptime commitments. For Meraki, this includes: firmware management practices (are you running supported versions?), redundancy configurations (do critical sites have failover?), monitoring and alerting (will you know when something goes down?), and capacity management (are you tracking utilization against thresholds?).

The Meraki Settings Your Auditor Will Check

Based on common SOC 2 audit requests across enterprise Meraki environments, here are the specific configurations and evidence artifacts your auditor is likely to evaluate:

Admin access review: A complete list of organization admins with their roles, last login dates, and 2FA status. Evidence that access reviews are performed quarterly. Documentation of any admin additions or removals during the audit period.

Network segmentation: VLAN configurations showing separation of sensitive data environments. Firewall rules between VLANs that enforce segmentation. Group policies that restrict client access to appropriate network segments.

Wireless security: SSID configurations showing WPA2/WPA3-Enterprise for corporate networks. RADIUS or certificate-based authentication for networks accessing sensitive data. Guest network isolation from production environments.

Configuration change logs: A complete audit trail of all configuration changes during the assessment period. Each entry should show the timestamp, the administrator who made the change, the specific setting modified, and the previous and new values.

Firmware management: Evidence that firmware versions are tracked and updated. A defined process for evaluating and deploying firmware updates. Documentation of any networks running unsupported firmware versions with remediation timelines.

Common SOC 2 Findings in Meraki Environments

After supporting compliance across hundreds of Meraki deployments, these are the findings we see most frequently:

Stale admin accounts. Former employees, contractors, or vendor accounts that still have active dashboard access. This is the single most common finding and the easiest to prevent with regular access reviews.

Inconsistent segmentation across sites. The VLAN and firewall configuration at headquarters is compliant, but 15 branch offices have slightly different configurations that don’t meet the same standards. This drift accumulates silently over time.

No configuration baseline. When auditors ask “what is the intended configuration for these controls?” and the answer is “whatever’s currently deployed,” that’s a gap. You need a documented, approved baseline that represents the desired state — separate from the actual state.

Incomplete change logs. The Meraki changelog captures dashboard changes, but API-driven changes, bulk operations, and template pushes may not be captured with sufficient detail for audit purposes.

Missing rollback evidence. Auditors increasingly ask: “If a change breaks something, can you demonstrate that you can restore the previous configuration?” Without config backup and tested restore procedures, this becomes a finding.

Building Continuous SOC 2 Compliance

The shift from Type I (point-in-time) to Type II (period of time) SOC 2 reports means auditors are evaluating how your controls operated over 6-12 months — not just how they look on audit day. This fundamentally changes the approach.

You need continuous monitoring that tracks configuration compliance against your baseline throughout the year. Every deviation should be captured, evaluated, and either remediated or documented as an approved exception. When your auditor arrives, the evidence should already exist — not require assembly.

Boundless Safeguard provides this continuous compliance layer for Meraki environments. It maintains your configuration baseline, detects drift in real time, attributes every change, and generates the audit evidence SOC 2 Type II requires — automatically, across every network in your organization.

Read the complete guide to Meraki compliance and audit for a broader overview of how to approach network compliance across multiple frameworks.