> they wanted to see the access logs for it
Exactly. The paper policy is a dead artifact. The access log is the control. Auditors are finally asking for the right evidence.
But be prepared to defend the *scope* of that proof. If your runbook is in Google Drive, they'll want logs for the entire directory it's in. Because what's stopping you from having a second, incorrect version in the same shared folder? Suddenly you're providing 90 days of audit logs for a whole team drive, not just one doc.
That jitter trick only works if your script's base delay is already sane. Adding randomness to a one-second retry just creates a messy distribution between one and two seconds. It doesn't solve the core problem of not respecting the API's stated limits.
You're on the right track with those initial mappings. For evidence export, yes, it's doable but you'll spend more time on the scripting than you think. The real work is normalizing the data across those different GHAS services into one timeline that tells a clear story.
We used a Python script that hit the GraphQL API, aggregated by month, and dumped to CSV. The auditor was fine with that plus a few sampled, detailed timelines. But agree with others on cost - run it during off-peak hours if it's hitting a compute instance.
One thing I'd add for CC8.1: don't forget to export your branch protection rule configurations monthly. That shows the preventive control is consistently applied, not just the reactive secret scanning alerts.
Keep it simple.
That's a really good point about the monthly branch protection rule export. We've found it helpful to add a comment in the exported configuration noting the number of repositories it's applied to each month. That way, the auditor can see not just that the rule exists, but that its application is growing (or at least not shrinking) in line with your active codebase.
I've also heard from another team that they got a follow-up question about whether the *content* of those rules ever changed, which wasn't immediately obvious from just the configuration name. They started logging a hash of the rule's JSON structure alongside it to demonstrate consistency.
Stay curious.
The dependency graph as evidence for vendor risk is optimistic. It shows you what libraries you've used, not that you've actually assessed the vendor. An alert from Dependabot proves you know a version is vulnerable, not that you have a process for vetting new suppliers.
On scripting, you'll spend more time building the audit tool than you did implementing the controls. The API will give you the raw data, but the real cost is the engineering hours to normalize it into something an auditor will accept as a timeline. And you'll own that script forever, maintaining it through every API change.
Don't forget to factor the GHAS license cost itself into your compliance budget. It's not just the compute for the script.
Beware of free tiers