Is Cisco Meraki SOC 2 or PCI DSS Compliant?
Quick answer. Cisco states the Meraki dashboard holds SOC 2 Type II, ISO/IEC 27001, 27017, and 27018 certifications, plus PCI DSS v4.0 certification, with documentation available through the Cisco Trust Portal. That covers Meraki's own infrastructure. Your own SOC 2 or PCI DSS scope still depends on how you configure Meraki's network segmentation, firewall rules, and change logging, which is where most Meraki-related audit findings actually happen.
Cisco Meraki shows up in a SOC 2 or PCI DSS audit two different ways, and it's easy to conflate them. First, Meraki as a vendor: what Cisco has certified about its own dashboard and datacenters. Second, Meraki as a control: what your own network configuration proves about segmentation, access, and change management inside your environment. Here's what we could confirm on each, and what to verify directly.
What Cisco has certified for Meraki
Verified against Meraki's Trust page and the Cisco Trust Portal.
| Certification / framework | What Cisco states |
|---|---|
| SOC 2 Type II | Meraki dashboard holds a SOC 2 Type II report; audit standard developed by the AICPA covering security, availability, processing integrity, confidentiality, and privacy |
| ISO/IEC 27001 | Meraki maintains a certified ISMS |
| ISO/IEC 27017 | Cloud-specific security controls beyond ISO 27001, confirmed achieved |
| ISO/IEC 27018 | PII protection in the cloud, confirmed achieved |
| PCI DSS | Meraki dashboard is PCI DSS v4.0 certified; Meraki datacenters separately hold PCI Level 1 Service Provider certification |
| BSI C5 | German cloud security certification, confirmed |
| FedRAMP | Meraki US Government Region holds Class C (Moderate) certification |
| ENS, ACN, ISMAP | Spain, Italy, and Japan national/regional cloud security frameworks, confirmed |
Common gap
This is the gap we flagged rather than guess at: Meraki's own trust page says its certifications can be "downloaded from the Cisco trust portal (search 'Meraki')," but our own check of the Trust Portal's public listing surfaced named trust packages for AppDynamics, CX Cloud, Webex Meetings, and Umbrella, without a Meraki-specific package visible on that public page. That doesn't mean Meraki documentation isn't there, portal contents are often account-gated and not fully visible from the outside, but we couldn't independently confirm it from public pages alone. Search the portal directly under your own Cisco account, or request the SOC 2 report by name through your Cisco or Meraki account team, and get written confirmation of exactly what you're receiving before you file it with your auditor.
We could not verify a specific SOC 2 report issue date, audit period, or the exact list of AICPA trust service categories covered (some vendors scope only Security, others add Availability and Confidentiality) without direct portal access. Request the full report if your auditor needs the audit period and scoped criteria as subservice organization evidence.
Source: Cisco Meraki Trust, Cisco Trust Portal.
PCI DSS: certification versus configuration
Meraki's dashboard-level PCI DSS v4.0 certification and PCI Level 1 datacenter certification cover Cisco's own infrastructure. They do not certify your network. Whether your cardholder data environment (CDE) is actually in scope, and stays out of scope where you want it to, comes down to how you configure the network, not which Meraki hardware you bought.
Per Meraki's PCI compliance documentation, there are two supported approaches:
- Complete isolation. Put wireless networks on physically separate wired infrastructure with an independent internet connection, fully disconnected from the CDE.
- Firewall segmentation. Connect wireless LANs to the same environment as the CDE, but isolate them with perimeter firewall rules. PCI DSS Requirement 1.2.3 specifically requires firewalls between any wireless network and the CDE, configured to deny or control any traffic from the wireless side into it. Meraki's LAN Isolation feature enforces this when it's enabled on every relevant SSID, not just some of them.
Common gap
Meraki's own documentation states plainly that "VLANs cannot be relied upon for network segmentation" on their own, since hackers can potentially cross VLAN boundaries without proper access controls between them. Auditors treat a VLAN diagram as a starting point, not proof of segmentation. They want to see the actual firewall rules enforcing the boundary.
Meraki also ships a built-in PCI Report tool (Monitor tab, MR wireless networks) that checks a network's settings against PCI DSS wireless requirements and returns pass/fail results with remediation guidance. Note that the tool we found documented tests against PCI DSS v2.0 and v3.0 wireless requirements specifically, a legacy naming convention in Meraki's own docs; confirm with your QSA that the checks it runs still map cleanly to the v4.0 requirement numbers your audit is scoped against before relying on it as your sole segmentation evidence.
Source: Meraki PCI Compliance documentation.
Meraki as evidence for your own SOC 2 or ISO 27001 audit
Meraki configuration and dashboard logs double as evidence for controls that have nothing to do with Cisco's own certifications, they're evidence about how you run your network.
SOC 2 CC6.6 and CC6.7, ISO 27001 Annex A network security: segmentation and firewall rules
Your MX firewall rules and VLAN configuration are the evidence for logical access restrictions and boundary protection. Pull an export of the current firewall rule set and the VLAN assignment for any network in scope, not just a topology diagram. If cardholder data or sensitive customer data is involved, LAN Isolation status on every relevant SSID matters as much as the firewall rules do.
SOC 2 CC8.1: change management
Meraki's Organization > Change Log records configuration changes across the organization, not just administrative Dashboard changes, but changes to switches, access points, firewalls, and other managed devices. Each entry logs the time (UTC), the admin who made the change, the network, the Dashboard page, and the old and new values. Retention runs 12 months in the EU and up to two years elsewhere, and the log is available via the Meraki Dashboard API as well as the UI.
What auditors look for: a Change Log export covering the audit period showing who changed what and when, an admin roster showing who holds change access, and, where you claim a change approval process, evidence that changes were reviewed before or shortly after they were made, not just recorded after the fact.
SOC 2 CC6.1 and CC6.3: role-based access
Meraki dashboard administrators can be scoped to full, read-only, or network-specific roles. An export of the admin roster showing who holds full organization access, and how often that list is reviewed, is standard evidence for least-privilege and access-review controls.
Gaps that show up at audit
Firewall segmentation exists but LAN Isolation isn't enabled everywhere. Segmentation rules configured on one SSID or VLAN and skipped on another is one of the more common PCI findings in Meraki environments; auditors check every in-scope SSID, not a sample.
Relying on VLANs alone as the segmentation story. Meraki's own documentation warns against this. If firewall rules between the VLAN and the CDE aren't documented and enforced, a VLAN diagram alone will not satisfy a QSA.
Change Log evidence pulled at year-end instead of retained continuously. The Change Log's 12-to-24-month retention window is generous, but if your audit period predates when you started actively reviewing it, you may be producing raw logs with no evidence anyone was watching them during the period.
Citing Meraki's dashboard certification as your own. Meraki's SOC 2 and PCI DSS certifications cover Cisco's infrastructure and dashboard, not your network configuration, your CDE scope, or your own control environment. Your auditor still tests your Meraki setup independently.
Confusing the 2015 HIPAA whitepaper for a current attestation. Meraki's HIPAA materials describe how segmentation and encryption support the technical safeguards; they are not a signed Business Associate Agreement and the whitepaper we found predates several HIPAA guidance updates. If you need a BAA, request it separately from your Cisco account team.
Reconciling Meraki's segmentation and firewall configuration against your actual SOC 2 or PCI DSS scope, and confirming exactly which Cisco Trust Portal documents you can cite, is exactly the kind of evidence work a fractional CISO runs before your auditor asks. Book a call or see pricing if you want your network segmentation evidence reviewed before your next audit.