How to Automate SOC 2 Evidence Collection

The work of a SOC 2 (System and Organization Controls 2) audit is mostly evidence work, and most of that evidence already lives in systems that expose an API. That is why you can automate SOC 2 evidence collection: instead of one analyst screenshotting the same console screens every cycle, you pull control evidence from your cloud provider, identity provider, and code repositories on a schedule. Done well, the audit stops being a project and becomes a byproduct of operations.

This guide covers which SOC 2 controls automate cleanly, how to pull evidence from cloud and code on a schedule, why structured evidence beats screenshots, and how continuous collection changes the shape of your audit. The commands below come from the open-source claude-grc-engineering toolkit, so you can run them yourself rather than take my word for it.

Which SOC 2 controls automate cleanly

SOC 2 is built on the Trust Services Criteria. Not every criterion is a good automation target. The dividing line is simple: if the evidence is a system configuration, you can query it. If the evidence is a human decision or a policy document, you cannot. Start with the controls that sit firmly on the queryable side.

• CC6.1 logical access: Who can access what, enforced by identity and cloud configuration. Evidence includes MFA enforcement, IAM policies, role assignments, and password settings, all readable from AWS, GCP, and Okta.
• CC6.6 boundary protection: Controls at the edge of the system. Evidence includes security group rules, public exposure of storage, and network segmentation, all queryable from your cloud provider.
• CC7.2 system monitoring: Detection of anomalies and security events. Evidence includes whether logging is enabled, whether trails are immutable, and whether monitoring rules exist, readable from CloudTrail, Config, and Security Hub.
• CC8.1 change management: How changes reach production. Evidence includes branch protection, required reviews, and pipeline gates, all readable from your version control and code repositories.

Controls like CC1.x (the control environment) and CC2.x (communication) still depend on board oversight, policy approvals, and training records. Automate the configuration controls first, because that is where the repetitive screenshot work concentrates. If GRC (Governance, Risk, and Compliance) engineering is new to you, GRC automation covers the broader approach this builds on.

Pull evidence from cloud and code on a schedule

You collect evidence with a connector, a thin plugin that wraps a tool you already use and turns its output into a structured finding. For change management evidence (CC8.1), run the GitHub connector against your repositories:

/github-inspector:collect --scope=@me

That inspects branch protections, required reviews, Actions, secret scanning, and Dependabot, which is most of what CC8.1 asks you to prove. For logical access and monitoring evidence (CC6.1, CC6.6, CC7.2), run the cloud connector:

/aws-inspector:collect --profile=default --region=us-east-1

The AWS connector covers IAM, S3, EBS, RDS, CloudTrail, VPC, Security Hub, and Config. GCP, GitHub, and Okta connectors follow the same shape, so identity evidence from Okta and cloud evidence from GCP land in the same format. The point is that nobody is pasting console screenshots into a folder. You are producing machine-readable evidence on demand.

The schedule is what matters. The same commands run unattended, so you can collect nightly or weekly and store the findings over time. A single run is useful for an audit. A standing schedule is what changes how your program operates, because the evidence is already there the day the request arrives.

Why structured evidence beats screenshots

A screenshot proves one thing at one moment, and only to the person who took it. It carries no context a machine can read, it cannot be diffed against last quarter, and it goes stale the moment the configuration changes. Structured evidence carries the context inside the data. Every connector emits findings against one shared contract, where one finding is one resource with one or more control evaluations. Here is a SOC 2 example:

{
  "schema_version": "1.0.0",
  "source": "aws-inspector",
  "collected_at": "2026-06-19T02:00:00Z",
  "resource": {
    "type": "aws_iam_account",
    "id": "123456789012",
    "uri": "arn:aws:iam::123456789012:root"
  },
  "evaluations": [
    {
      "control_framework": "SOC2",
      "control_id": "CC6.1",
      "status": "fail",
      "severity": "high",
      "message": "MFA is not enforced for 3 IAM users with console access.",
      "remediation": {
        "summary": "Require MFA for all human IAM principals.",
        "effort_hours": 1,
        "automation": "guided"
      }
    }
  ]
}

Read what that gives you. A specific resource, a specific control (CC6.1), a pass or fail status, a severity, a plain-language message, and a remediation with an effort estimate and a collection timestamp. That is audit-grade evidence a reviewer can act on. It is also queryable, so you can answer "show me every failing CC6.1 finding this quarter" without opening a single screenshot.

Map findings to SOC 2 controls

Collecting evidence is half the job. The other half is proving each finding maps to the right control. The toolkit runs that mapping through the Secure Controls Framework crosswalk, a maintained catalog rather than a hand-built spreadsheet. After you collect, run a gap assessment against SOC 2:

/grc-engineer:gap-assessment SOC2 --sources=aws-inspector,github-inspector

That joins your collected findings to the SOC 2 Trust Services Criteria and shows where you have coverage, where you have gaps, and which findings still need a human decision. Because the crosswalk is bidirectional, the same collected evidence can support another framework later without re-collecting anything:

/grc-engineer:gap-assessment SOC2,ISO-27001-2022 --sources=aws-inspector,github-inspector

The cached findings are reused and only the crosswalk join re-runs. One MFA failure now shows up correctly against SOC 2 and ISO/IEC 27001:2022 at the same time, with no mapping table that only one person on the team understands. The deeper walkthrough of crosswalking lives in How to Automate Compliance Evidence and Control Mapping with AI.

How continuous collection makes the audit a byproduct

SOC 2 Type 2 audits cover a period, usually six or twelve months, not a single day. That is exactly why scheduled collection fits the framework so well. When you collect on a schedule, you accumulate a history of structured findings across the entire observation window. The auditor is not asking "is this control in place today." They are asking "was it in place every day of the period," and a run history answers that directly.

Two things happen when evidence accumulates this way. The audit stops being a project and becomes a byproduct of normal operations, because the evidence already exists when the auditor asks for it. And you gain a history you can diff, so a control that quietly drifted out of compliance shows up as a status change between runs rather than a surprise during fieldwork. The toolkit supports standing monitoring with alerting through /grc-engineer:monitor-continuous, so a new CC7.2 monitoring gap can notify the right channel the moment it appears.

This is the shift from point-in-time evidence to a living control posture, and it is the single highest-leverage change most SOC 2 programs can make. The mechanics of running that on a recurring basis are covered in continuous compliance monitoring.

Keep a human in the loop before the workpaper

Automating evidence collection does not mean unattended compliance. Because findings are structured, they are reviewable and diffable. You can see what changed between runs, challenge a status, add context the connector could not see, and sign off before anything becomes a workpaper. Treat the output like a pull request from a fast junior analyst: review it, then merge it. The automation does the collection and the mapping. The accountability stays with a person.

For the command-level walkthrough of the full pipeline, see How to Use Claude Code for GRC and Compliance Automation. To build the hands-on skills behind this workflow, the GRC Engineering Club Academy pairs the toolkit with guided labs.

Frequently Asked Questions