I've been conducting a detailed evaluation of Secureframe for our organization's SOC 2 Type II compliance program, with a particular focus on its automated evidence collection capabilities. While the platform's general concept for integrating with identity providers is sound, I've identified a significant and persistent gap in its Google Workspace integration that appears to undermine a core compliance control.
The issue centers on the auditing of external file sharing. Specifically, the integration does not appear to comprehensively collect or correctly categorize evidence related to the `Drive` audit log event `CHANGE_ACL` (Change access control list). This event is critical for demonstrating control over who has access to sensitive documents, especially those shared externally. Our manual reviews of Google's native audit logs consistently show sharing events that are not reflected in Secureframe's "Collected Evidence" panel for the relevant control (e.g., controls pertaining to least privilege or access review).
**What we've observed:**
* Secureframe successfully collects data on user provisioning/de-provisioning and group membership from the `Admin` audit log.
* It captures some `Drive` events, like document creation or deletion.
* The `CHANGE_ACL` events, which are the definitive log for sharing a file/folder externally or modifying its permissions, are either missing entirely or are not being parsed into a usable evidence format.
**Our configuration context:**
We have the integration configured via a dedicated service account with the following OAuth scopes (as recommended by Secureframe):
```
https://www.googleapis.com/auth/admin.reports.audit.readonly
https://www.googleapis.com/auth/admin.reports.usage.readonly
https://www.googleapis.com/auth/drive.readonly
```
The scope set seems appropriate. The problem likely resides in the data ingestion pipeline or the evidence mapping logic on Secureframe's backend.
Has anyone else in the community performed a technical deep-dive and encountered this same discrepancy? I'm particularly interested in:
* Corroboration of this specific gap.
* Any workarounds implemented, such as custom script-based evidence collection for this specific control, and how you managed the attestation within the Secureframe framework.
* Official communication from Secureframe support regarding a timeline for a resolution. Our initial inquiries have only yielded generic "our engineering team is aware" responses without technical details.
Without reliable automated evidence for this vector, the alternative is manual log reviews and screenshots, which defeats a primary value proposition of the platform for this control set. I'm concerned this may be a systemic issue in how the integration parses the Google Workspace Activity API response.
infra nerd, cost hawk
Yeah, this tracks. I've seen similar gaps when pulling data from Google into other platforms for audits. The admin log stuff is usually straightforward, but Drive's event logs, especially around sharing permissions, are a different beast.
We ran into this with a HubSpot Workspace sync for sales collateral. The audit would show a file was shared with a client domain, but the platform's "access review" report would list it as internal-only. Had to build a custom script to pull the CHANGE_ACL events directly from the Google API and map them ourselves. Defeated the whole purpose of the "automated" evidence collection.
Have you checked if the integration scope in your Secureframe setup has the full Drive audit scope, and not just the basic Admin SDK? Sometimes the default setup misses the deeper permissions audit trails.
The scope point is critical. We've seen platforms request the ` https://www.googleapis.comuth/admin.reports.audit.readonly` scope, which gets you Admin Activity reports, but for detailed Drive events you need the more granular ` https://www.googleapis.comuth/drive.activity.readonly` scope as well. Even with that, mapping the `CHANGE_ACL` event to a human-readable policy violation is non-trivial; the API payload requires parsing the `primaryActionDetail` object and then cross-referencing the new permission with your internal domain list. I'm not surprised a custom script was necessary.
What was the performance hit on your script pulling those events directly? In our testing, querying the Drive Activity API at scale for a full audit period introduced noticeable latency versus the Admin Reports API, often taking multiple minutes to return a complete dataset. This makes real-time or near-real-time monitoring difficult.
—chris
Interesting, I ran into something similar with a different compliance platform. It captured admin logins just fine, but completely missed Google Drive file shares. Are these platform integrations just using the wrong API endpoint by default?
You mentioned manual reviews of Google's native logs. What path did you take to do that comparison? I'm trying to validate my own setup but find the native audit log UI a bit overwhelming for a beginner.