The Problem with Raw Compliance Scans
You run your first compliance scan against a Meraki network. It comes back with 400+ individual checks. Some are genuine issues — an open SSID here, a missing syslog configuration there. But mixed in with the real findings are results like:
- "No Meraki cameras present" — because you use a third-party CCTV system
- "SNMP v2c enabled" — because your monitoring tool requires it and you have mitigated the risk with network segmentation
- "Appliance in passthrough mode" — because it sits behind another firewall by design
- "80% of switch ports unnamed" — because labelling 2,000 ports across 40 sites is not happening this quarter
You fix what you can. You re-scan next month. The same unfixable findings come back. Your compliance score is stuck at 55% even though every actionable issue has been addressed. Your client or your auditor sees a report full of red, and you spend more time explaining why those findings are acceptable than you do on actual remediation.
This is the compliance noise problem. And it is the reason most compliance tools end up unused after the first assessment cycle.
Three Layers of Exception Management
MerakiGuard handles this with three distinct mechanisms, each designed for a different scenario. Together, they let you acknowledge known findings, carry decisions forward between scans, and permanently exclude checks that do not apply to your environment.
When a scan result is a genuine finding but you have evaluated the risk and decided it is acceptable, you can accept the risk directly from the scan results page. You provide a written justification — the compensating control, the business reason, or the risk acceptance decision.
Accepted findings are tagged in the results, and the compliance score is adjusted upward to reflect that these are acknowledged decisions, not ignored problems. The raw score is still visible for transparency, but the adjusted score gives a more accurate picture of your actual compliance posture.
Critically, the justification is preserved in the scan record and included in PDF reports. When an auditor asks "why is this marked as acceptable?", the answer is right there next to the finding.
You accepted a risk last month. You re-scan this month. The same finding appears — but this time, MerakiGuard recognises that you already made a decision about this exact check on this exact resource.
A banner at the top of the scan results page tells you how many findings have matching risk acceptances from the previous scan. You can review them in a modal, confirm which ones should carry forward, and apply them in bulk with a single click.
This is deliberately not automatic. Compliance decisions should be reviewed periodically — a risk you accepted six months ago may no longer be valid. Carry-forward gives you the efficiency of not re-typing the same justification every month, with the governance of explicit human review.
Some checks simply do not apply to your environment. You do not have Meraki cameras. You will never have Meraki cameras. The "cameras present" check will fail on every scan for the rest of time.
For these cases, you can exclude a check entirely from future scans for a specific organisation. The exclusion is recorded with a reason and timestamp. Excluded checks are skipped during scan execution — they do not affect your compliance score, and they do not clutter your results.
Exclusions are managed on the organisation settings page, where you can see every excluded check and re-enable any of them at any time. They also appear in a dedicated section at the end of PDF reports, so auditors have full visibility into what was excluded and why.
When to Use Which
The distinction matters. Each mechanism serves a different purpose:
- Risk Acceptance — the check is relevant, the finding is real, but you have a compensating control or a documented business reason. "We use a captive portal for guest WiFi instead of WPA2. This is by design."
- Carry-Forward — you already made this decision last scan and nothing has changed. "Same guest WiFi finding, same justification, still valid."
- Check Exclusion — the check does not apply to this organisation at all. "We don't use Meraki cameras. This check will never pass and should not be evaluated."
Think of it as a spectrum: risk acceptance is per-finding, per-scan. Carry-forward is per-finding, across scans. Exclusion is per-check, permanent (until re-enabled).
What This Means for Your Compliance Score
Without exception management, your compliance score is a number that says "here is how your network configuration compares to a theoretical ideal." That number is accurate, but it is not useful. It penalises you for things you cannot change and buries the signal in noise.
With exception management, you get two scores:
- Raw score — the unfiltered assessment, exactly as the checks report it
- Adjusted score — the score after accounting for accepted risks and excluded checks
The gap between these two numbers tells a story. A raw score of 52% with an adjusted score of 88% means you have a network with a lot of known, documented exceptions and a strong actual compliance posture. A raw score of 52% with an adjusted score of 54% means you have real work to do.
Both numbers are visible throughout the platform — on the scan detail page, on the per-standard scorecards, and in PDF reports. Nothing is hidden.
The MSP Angle
If you manage Meraki networks for multiple clients, exception management is not just a convenience feature — it is what makes monthly compliance reporting viable.
Without it, here is what happens: you send a client their first compliance report. It has 40 findings. They fix 25 of them. Next month, you send another report. It has 15 findings. Same 15 as last month. The client asks why their score has not improved. You explain. Again. Every month.
With exception management:
- Month one: 40 findings. Client fixes 25, accepts risk on 10, excludes 5 checks that do not apply.
- Month two: 0 new findings. Previous risk acceptances are reviewed and carried forward. Score: 93%. Report takes two minutes to generate and is immediately useful.
- Month three: 2 new findings — someone changed a firewall rule and forgot to update an SSID. These stand out immediately because all the noise has been cleared.
That is the difference between a compliance tool your clients dread and one they actually want to see every month.
Audit Trail and PDF Reports
Every decision is recorded. Risk acceptances include who accepted, when, and why. Exclusions include the reason and the date. All of this flows into the PDF compliance report:
- Accepted findings are marked in the results tables with their justification
- Excluded checks appear in a dedicated appendix at the end of the report, listing the check name, standard, control reference, and reason for exclusion
- Both raw and adjusted scores are shown so auditors can see the full picture
The goal is transparency. An auditor should be able to read the report and understand not just what passed and failed, but what was evaluated, what was excluded, and why every exception was made. No surprises.
Getting Started
Exception management is available on all paid MerakiGuard plans. Here is how to start using it:
- Run a scan. Let MerakiGuard evaluate your Meraki network against CE+, PCI-DSS, NIST CSF, and CIS Benchmarks.
- Review your findings. For each failed or warning result, decide: is this something to fix, something to accept, or something to exclude?
- Accept or exclude. Use the buttons on each scan result to accept risk (with a justification) or exclude the check from future scans.
- Re-scan next month. Review the carry-forward banner, confirm your previous decisions still apply, and focus your attention on genuinely new findings.
Your compliance score will start reflecting your actual posture instead of a theoretical ideal. Your reports will be clean enough to send directly to clients or auditors. And you will stop explaining the same 15 findings every month.