How to Build a Google Workspace Mobile Device Compliance Dashboard (AC.L2-3.1.18)

Build a Google Workspace mobile device compliance dashboard by combining Endpoint Management inventory, Admin audit activity, login events, and an approved-device register into measurable KPIs for device identification, authorization, and monitoring. For CMMC 2.0 Level 2 practice AC.L2-3.1.18, the dashboard should show which mobile devices can access CUI-related Workspace data, whether each device is authorized and managed, and whether device events are being reviewed and retained as evidence.

Why do metrics matter for AC.L2-3.1.18?

NIST SP 800-171 Rev. 2 and CMMC 2.0 Level 2 practice AC.L2-3.1.18 require an organization to control mobile-device connections. A written mobile-device policy is necessary, but it is not sufficient evidence that the control operates continuously. Assessors and customer security contacts need to see that the organization can identify mobile devices, authorize their connection, and monitor activity over time.

For an MSSP analyst, metrics turn a tenant’s mobile-device configuration into an operational compliance story. Rather than reporting, “Advanced Endpoint Management is enabled,” report that 98% of devices with access to the CUI Google Group have a unique device identifier, are enrolled in management, and meet the customer’s approved-device policy. The remaining 2% becomes a defined exception queue with an owner and remediation date.

The most useful metrics are scoped carefully. Do not treat every employee phone that has ever synchronized Gmail as a CUI device. Define the population as mobile devices used by accounts authorized to access CUI, sensitive projects, controlled shared drives, or designated CUI organizational units. This avoids overstating exposure while ensuring tablets, smartphones, and other portable endpoints are not omitted.

Which KPIs belong on a Google Workspace mobile device compliance dashboard?

The following KPIs provide a practical monthly scorecard for SMB customers. Targets are example operating thresholds; each customer should approve its own thresholds, exception process, and definition of a CUI-capable mobile device.

Keep the KPI denominators visible. For example, “18 of 18 CUI-scope devices are enrolled” is more defensible than a green 100% indicator without context. Also show the count of devices excluded from scope and why: no CUI access, retired device, pending offboarding, or approved exception.

How often should mobile-device compliance be reported?

Use a layered reporting cadence. Automated collection should run daily, because device enrollment and user access can change quickly. The MSSP analyst should review exceptions weekly, especially devices that are unmanaged, inactive, unknown, or associated with terminated users. Provide customers with a monthly compliance report and preserve the underlying export, screenshots, and ticket references in the evidence repository.

What should the monthly customer report contain?

• A current device population summary: total mobile endpoints, CUI-scope endpoints, managed endpoints, and authorized endpoints.
• The seven KPI results, prior-month values, target thresholds, and a simple trend indicator.
• An exceptions table listing device identifier, assigned user, issue, discovery date, ticket number, assigned owner, and due date.
• A log-review statement identifying the review period, reviewer, source systems, notable events, and disposition of each significant event.
• A configuration-change summary for Endpoint Management policies, allowed device types, access rules, and administrator actions.

For evidence retention, retain the monthly PDF or customer-facing report, raw CSV or API export, exception tickets, and approval records according to the customer’s records-retention policy. The report demonstrates oversight; the source exports and ticket trail make the report verifiable.

How do you build a Google Workspace mobile device compliance dashboard?

A practical Google Workspace mobile device compliance dashboard can be built with Google Admin console exports, the Admin SDK Directory API, the Reports API, Google Sheets, and Looker Studio. For larger or more regulated customers, send normalized daily extracts to BigQuery and connect Looker Studio to the BigQuery dataset. Keep each customer in a separate dataset, spreadsheet, or reporting workspace to prevent cross-tenant exposure.

What data should the dashboard collect?

• Endpoint inventory: device ID, serial number where available, user email, model, operating system, ownership, enrollment status, encryption status, screen-lock status, last sync, and last user activity.
• Authorization register: approved user, device identifier, CUI scope, owner, approval date, expiration date, and exception status.
• Administrative audit activity: mobile-device management actions, policy changes, wipes, blocks, approvals, and administrator identity.
• Identity activity: login events and account status changes that help explain whether an endpoint remains associated with an active authorized user.
• Ticketing data: issue severity, remediation owner, opened date, resolved date, and approved exception reference.

The Admin SDK Directory API can provide the inventory feed. A service account should use domain-wide delegation only when approved by the customer, and the delegated administrator should have the minimum required read permissions.

GET https://admin.googleapis.com/admin/directory/v1/customer/my_customer/devices/mobile?projection=FULL&maxResults=100

Authorization: Bearer <delegated-access-token>

Normalize the response into a daily table with fields such as snapshot_date, device_id, user_email, model, os, managed, encrypted, screenlock_enabled, and last_sync. Do not use a user email alone as the device identifier; users can change, share devices, or have multiple devices. The Google endpoint device ID should be the primary correlation key, with serial number or asset tag used when available.

For the dashboard’s exception widget, a normalized BigQuery table can identify devices that are in the CUI scope but lack management, authorization, or recent synchronization:

SELECT
  d.device_id,
  d.user_email,
  d.model,
  d.last_sync,
  CASE
    WHEN a.device_id IS NULL THEN 'No authorization record'
    WHEN d.managed != TRUE THEN 'Not enrolled in management'
    WHEN d.encrypted != TRUE THEN 'Encryption noncompliant'
    WHEN d.screenlock_enabled != TRUE THEN 'Screen lock noncompliant'
    WHEN TIMESTAMP_DIFF(CURRENT_TIMESTAMP(), d.last_sync, DAY) > 30
      THEN 'No sync in more than 30 days'
    ELSE 'Compliant'
  END AS compliance_status
FROM `customer_workspace.mobile_device_snapshot` d
LEFT JOIN `customer_workspace.approved_device_register` a
  ON d.device_id = a.device_id
WHERE d.cui_scope = TRUE;

For audit collection, pull Admin audit activity through the Reports API and retain the raw event payload. Event names and parameters can vary by Workspace edition and administrative action, so validate the events present in each tenant before building filters. The dashboard should display event counts and review status, while the retained raw log supports investigation and assessor sampling.

How should you present mobile-device compliance to leadership?

Leadership does not need an endpoint-by-endpoint inventory on the first page. Lead with three answers: how many CUI-scope mobile devices exist, how many meet policy, and what risk remains. A useful executive summary might state: “Twenty-four mobile devices are authorized for CUI-related Workspace access; 23 meet all required controls, and one Android tablet is pending encryption remediation under ticket SEC-1842, due July 22.”

Use a trend line for managed-device enrollment, a monthly exception count, and remediation-SLA performance. Pair red or amber results with a business decision: block access, remediate, accept a time-bound exception, or remove CUI authorization. This connects AC.L2-3.1.18 reporting to accountable action rather than presenting a static compliance score.

For MSSP service reviews, separate customer-owned risk from provider-owned operations. The customer approves mobile-device policy, authorization criteria, and exceptions; the MSSP collects evidence, monitors metrics, opens tickets, and reports overdue remediation. That division makes the Google Workspace device compliance reporting package useful during both routine QBRs and CMMC assessment preparation.

Next step: Build the first customer dashboard from a current endpoint export and approved-device register, then review every unmatched CUI-scope device with the customer within five business days.