A security service edge (SSE) platform that looked complete at go-live can quietly stop protecting much of the estate: clients drop off laptops, bypass lists grow, data policies stay in monitor mode and new SaaS apps arrive faster than anyone reviews them. This health check is a recurring, measurable review of a live cloud access security broker (CASB) and SSE platform, covering the secure web gateway, CASB API and inline functions, data protection policies and the endpoint client. It turns the questions a security lead or auditor would ask into twelve metrics with formulas, thresholds and evidence, so each quarter can be compared with the last. It is written for SSE platform owners, network and cloud security leads, internal audit and the CISO's office.
This page measures; it does not explain how to design or harden the service. For architecture and traffic steering, read the SASE and SSE Guide; for protecting the platform's own admin roles, connectors and keys, use Securing the CASB and SSE platform itself, and go back to both for every finding this review raises.
What this health check covers
The review covers the platform's outward job: how much of your users' web and SaaS traffic it actually sees, how much of that it inspects, which sanctioned SaaS applications it protects through API connections, and whether its data and access policies are enforcing rather than observing. It applies whether the service is delivered as a standalone CASB, a cloud proxy with CASB features, or the security half of a SASE stack.
- Who runs it: the SSE platform owner collects the figures; the network or cloud security lead and the data protection lead review them; the CISO or delegate signs off red items.
- How it differs from the securing guide: the securing page measures the platform's self-protection (number of tenant administrators, connector credential rotation, policy change approval). This check measures coverage and enforcement across the estate, and refers back to the securing page for self-protection rather than repeating it.
- What it is not: a penetration test, a product evaluation or a configuration baseline scan. Those can feed individual metrics, but the health check is about whether the controls are still working this quarter.
- Common search terms it answers: "CASB audit checklist", "SSE KPIs", "secure web gateway coverage metrics" and "how to measure TLS inspection coverage".
Key takeaways
- Coverage comes before policy. Every enforcement figure describes only the traffic the platform sees; measure client coverage and steering coverage first, or every other metric flatters you.
- Bypass is the quiet failure. Track bypass and exemption entries with an owner and expiry, and the share of traffic leaving inspection, every quarter.
- Monitor mode is not protection. Count data protection policies that are actually blocking or coaching, against those that were meant to.
- Discovery without decisions is noise. Measure how many discovered SaaS apps above your usage threshold have a sanction decision, not how many were discovered.
- Thresholds are a starting point. The green, amber and red bands are NHI Mgmt Group recommendations; agree your own, record them and keep them stable so trends mean something.
How to use this template
Copy the metrics table and the findings log into your own tracker, then run this CASB and SSE platform health check at the cadence set out below. Collect each figure from the data sources described, score it against the green, amber and red thresholds, and record every amber or red result as a finding with an owner and a due date. Keep each completed review so you can compare results quarter on quarter: the trend matters as much as any single score.
Cadence and sign-off
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| Client coverage and log delivery dashboard | Weekly (automated) | SSE platform owner | Security operations lead | Dashboard snapshot, devices without a connected client |
| Bypass and exemption list review | Monthly | Network security lead | SSE platform owner | Exported bypass list with owner, reason, expiry and decision |
| Unsanctioned app triage | Monthly | SaaS governance or cloud security lead | Data protection lead | Discovered app list above threshold, sanction decisions with dates |
| Full metrics review (this page) | Quarterly | SSE platform owner | CISO or delegate | Metrics table with figures, raw exports, findings log |
| Independent sample test | Annually | Internal audit or second line risk | Audit committee or risk committee | Sample of devices, bypass entries and policies re-performed |
| Event-driven review | After a client upgrade, steering change, merger or incident | SSE platform owner | CISO or delegate | Before and after figures for metrics 01 to 04 |
Fix one measurement date per quarter (for example the last working day) and take every figure as at that date. Platform owners should not be the only people signing off figures about the platform's own coverage; this follows the separation of duties principle in NIST SP 800-53 Rev. 5 AC-5.
Metrics
NHI Mgmt Group recommended thresholds; adjust to your risk appetite. The formulas are recommended methods too: write down the numerator, denominator and data source once and reuse them every quarter. "Managed device" means a device in your endpoint inventory that should run the SSE client; "in scope" means on the list agreed in your SSE policy.
| ID | Metric | Formula | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| SSE-01 | Client coverage | Managed devices with the SSE client connected and reporting in the last 7 days ÷ managed devices in the endpoint inventory | SSE client inventory joined to the endpoint management or asset inventory | 98% or more | 90% to below 98% | Below 90% |
| SSE-02 | Traffic steering coverage | Outbound web sessions (or bytes) that passed through the SSE service ÷ outbound web sessions seen at the egress firewall, DNS resolver or proxy logs for the same users and sites | SSE transaction logs compared with egress firewall or DNS logs | 95% or more | 85% to below 95% | Below 85% |
| SSE-03 | TLS inspection coverage | HTTPS sessions decrypted and inspected ÷ HTTPS sessions through the service, after removing categories exempted by written policy (for example health and banking) | SSE transaction logs with the inspection or decryption flag | 85% or more | 65% to below 85% | Below 65% |
| SSE-04 | Bypass and exemption hygiene | Bypass, allow-list and inspection exemption entries with a named owner, reason and an unexpired review date ÷ all such entries | Exported policy configuration (bypass, exemption and steering lists) | 100% | 90% to below 100% | Below 90%, or any wildcard bypass of a whole SaaS or cloud domain without approval |
| SSE-05 | Unattributed traffic | Sessions with no authenticated user identity (anonymous, IP-only or service traffic not on the approved list) ÷ all sessions | SSE transaction logs (user field) and the identity provider integration status | Below 2% | 2% to 5% | Above 5% |
| SSE-06 | Sanctioned SaaS under API protection | Sanctioned SaaS tenants holding confidential data with a healthy API connection (successful scan in the last 24 hours) ÷ sanctioned SaaS tenants in scope | CASB API connector status list and the SaaS application register | 95% or more | 80% to below 95% | Below 80% |
| SSE-07 | Unsanctioned app decisions | Discovered cloud apps above your usage threshold (for example 10 users or 1 GB uploaded in the quarter) with a recorded sanction, tolerate or block decision ÷ discovered apps above the threshold | Shadow IT discovery report and the app decision register | 90% or more | 70% to below 90% | Below 70% |
| SSE-08 | Data policies enforcing | Data protection policies in block, coach or encrypt mode ÷ policies approved for enforcement in the data protection standard | Exported data protection policy set with mode and approval reference | 95% or more | 75% to below 95% | Below 75% |
| SSE-09 | Unmanaged device controls | Sessions from unmanaged devices to sanctioned SaaS that were subject to a session control (read-only, no download, block) ÷ all unmanaged device sessions to those apps | Inline CASB or reverse proxy session logs with the device posture field | 95% or more | 80% to below 95% | Below 80% |
| SSE-10 | Risky OAuth grants reviewed | Third-party OAuth apps and integrations with high-risk scopes in sanctioned SaaS that were reviewed and approved or revoked this quarter ÷ such grants discovered | CASB API connector findings for connected apps, SaaS admin audit logs | 95% or more | 80% to below 95% | Below 80% |
| SSE-11 | High-severity alert handling | High-severity data and threat alerts triaged within your service level ÷ high-severity alerts raised | SSE alert queue or the SIEM and case management records | 95% or more | 80% to below 95% | Below 80% |
| SSE-12 | Log delivery completeness | Hours in the quarter with SSE logs received in the SIEM within 15 minutes of the event ÷ hours in the quarter | SIEM ingestion metrics for the SSE log source | 99.5% or more | 98% to below 99.5% | Below 98%, or any gap over 24 hours |
Report the absolute count beside every percentage. A green percentage that hides one red privileged item (for example an executive's laptop permanently bypassed, or a wildcard exemption covering a file sharing service) is reported as red.
Self-protection figures for the platform itself (tenant administrator count, connector credential age, second approver on policy publication, connector software currency) sit in the Detection and measurement section of the securing page. Add them to this scorecard as a single line, "Platform self-protection", rated by the worst of those figures, rather than repeating them here.
How to collect the data
Every figure above comes from data sources that SSE platforms and the systems around them produce. Export raw rows, not dashboard percentages, and keep the exports with the findings log so the next quarter is calculated the same way.
- Freeze the date and the inventory: take the endpoint management inventory or asset inventory on the measurement date. This is the denominator for SSE-01 and the population for SSE-09. See the Asset Inventory and CMDB Security Guide if the inventory itself is unreliable.
- Client coverage: export the platform's list of enrolled clients with last-seen time and client version, join it to the inventory on device identifier or serial number, and list the devices that are missing or silent. The gap list is the finding, not the percentage.
- Steering coverage: compare a week of SSE transaction logs with egress firewall or DNS resolver logs for the same user population. Destinations that appear only in the firewall or DNS logs show traffic going around the service: split tunnel rules, direct routes or devices without a client.
- Inspection and bypass: from the transaction logs, count sessions flagged as decrypted against all HTTPS sessions. From the policy configuration export, list every bypass, allow and inspection exemption with its creation date, owner and review date. Keep last quarter's export so additions are visible.
- SaaS and API protection: export the CASB API connector status list (tenant, last successful scan, error state) and match it to the SaaS application register. Export the shadow IT discovery report for the quarter and match it to your app decision register. See the SaaS Security Guide.
- Policies and alerts: export the data protection policy set with each policy's mode, and the alert queue or SIEM case records for high-severity alerts with created and triaged times.
- Logging: pull ingestion volume per hour for the SSE log source from the SIEM and list any hour with no events or with delay beyond your service level.
- Sample the reds: for every red metric, check five to ten records directly (a device, a session, a bypass entry) to confirm the figure is real and not a data quality problem.
Red flags that need action now
- Any group of managed devices, such as a business unit or an operating system, with client coverage below 80%.
- A wildcard bypass or inspection exemption for a whole file sharing, storage or personal email domain.
- Bypass or exemption entries with no owner, or past their review date, for more than one quarter.
- Steering coverage falling by more than five percentage points quarter on quarter without a planned change.
- A sanctioned SaaS tenant holding confidential data whose API connection has failed for more than seven days.
- Data protection policies approved for blocking that are still in monitor mode six months after approval.
- Unattributed traffic above 5%, which usually means the identity provider integration or client sign-in is broken for a population.
- A gap of more than 24 hours in SSE logs reaching the SIEM.
- Client disable or uninstall events with no matching ticket. The If your CASB and SSE platform is compromised playbook covers what to do if these are deliberate.
Findings log
Keep one running log across quarters so repeat findings are visible. Escalate a finding that stays red for two consecutive quarters to the CISO, and one that repeats three times to the risk register.
| ID | Finding | Metric | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-SSE-01 | [n] managed devices in [business unit] with no connected client | SSE-01 | [Red / Amber] | [Endpoint team lead] | [Date] | [Open / In progress / Closed] |
| HC-SSE-02 | [n] bypass entries without owner or past review date | SSE-04 | [Severity] | [Network security lead] | [Date] | [Status] |
| HC-SSE-03 | API connection to [SaaS tenant] failing since [date] | SSE-06 | [Severity] | [SSE platform owner] | [Date] | [Status] |
| HC-SSE-04 | [n] approved data policies still in monitor mode | SSE-08 | [Severity] | [Data protection lead] | [Date] | [Status] |
| HC-SSE-05 | [Finding] | [Metric ID] | [Severity] | [Owner] | [Date] | [Status] |
Remediation map
| Finding type | Where to fix it |
|---|---|
| Low client coverage, split tunnel gaps, falling steering coverage | SASE and SSE Guide: steering traffic into the service |
| Low TLS inspection coverage, broad exemptions | SASE and SSE Guide: TLS inspection and data protection; M1020 SSL/TLS Inspection |
| Bypass entries without owner or expiry, configuration drift | Securing the CASB and SSE platform itself: bypass lists, configuration integrity and the platform's own logs |
| Failing API connectors, over-privileged connector accounts | Securing the CASB and SSE platform itself: the platform's identities, keys and trusts |
| Undecided shadow IT, unmanaged device sessions | CASB Guide: shadow IT discovery and app governance |
| Data policies stuck in monitor mode | Data Loss Prevention (DLP) Guide |
| Unreviewed high-risk OAuth grants | Consent Phishing and Illicit OAuth Grants Guide |
| Log gaps and late delivery | Log Management and Retention Guide |
Related guides
- Securing the CASB and SSE platform itself: the hardening page this check refers back to.
- SASE and SSE Guide: architecture, steering and inspection design.
- CASB and SSE platform maturity model: where the platform sits on a five-level scale.
- If your CASB and SSE platform is compromised: response when a red flag turns out to be an attack.
- ZTNA and remote access VPN health check and Data loss prevention (DLP) health check: companion checks for the private access and data protection estates.
- Security Metrics and KPIs Programme Guide: how to report these figures to leadership.
References
- NIST: SP 800-207 Zero Trust Architecture
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (AC-4 Information Flow Enforcement, AC-5 Separation of Duties, SC-7 Boundary Protection, SI-4 System Monitoring)
- NIST: Cybersecurity Framework 2.0 (DE.CM-01, PR.DS-02, PR.PS-04)
- CIS: Critical Security Controls v8.1 (Control 3 Data Protection, Control 9 Email and Web Browser Protections, Control 13 Network Monitoring and Defense)
- Cloud Security Alliance: Cloud Controls Matrix v4.1
Related NHI Mgmt Group resources: Securing the CASB and SSE platform itself, SASE and SSE Guide, CASB Guide, Secure Web Gateway and Web Filtering Guide.