If you are preparing for a SOC 2 Type II audit, the fastest path to a clean report is to automate SOC 2 evidence collection by wiring your control checks directly into the systems that already produce the data: your cloud provider, identity platform, ticketing tool, and CI/CD pipeline. Instead of chasing screenshots during audit week, you configure scheduled jobs and API pulls that capture timestamped evidence continuously across the audit period. The result is less manual work, fewer gaps, and evidence that auditors trust because it is generated by systems rather than assembled by hand.
Below I walk through how I approach this in practice, from mapping controls to building the automation, so your next Type II window is a reporting exercise instead of a fire drill.
Why Type II Makes Manual Evidence Collection Painful
A SOC 2 Type I report assesses whether controls are designed correctly at a single point in time. A Type II report assesses whether those controls operated effectively over a period, usually 3 to 12 months. That distinction changes everything about evidence.
For Type II, an auditor does not want one screenshot showing MFA is enabled today. They want evidence that MFA was enforced for every privileged user across the entire observation window, that access reviews happened on schedule, and that every production change went through review. Collecting that manually means:
- Repeatedly logging into consoles to capture the same screenshots
- Reconstructing what happened months ago from memory or scattered logs
- Discovering gaps only when the auditor samples a date you cannot cover
The fix is to treat evidence as a data pipeline problem. You capture control state on a schedule, store it immutably, and produce reports on demand.
Step 1: Map Controls to Systems of Record
Before automating anything, you need a control matrix that ties each control to the system that holds the authoritative evidence. Automation only works when you know exactly where the truth lives.
Start with the Trust Services Criteria your report covers (Security is mandatory; Availability, Confidentiality, Processing Integrity, and Privacy are optional). Then map each control to a source.
| Control area | Example control | System of record | Evidence artifact |
|---|---|---|---|
| Access management | MFA enforced for admins | Okta / Entra ID | Policy export + user list |
| Change management | Code reviewed before merge | GitHub / GitLab | PR approval logs |
| Vulnerability mgmt | Critical vulns remediated in SLA | Scanner + Jira | Ticket timestamps |
| Backups | Daily backups succeed | AWS Backup / RDS | Job status logs |
| Logging | Audit logs retained 1 year | CloudTrail / SIEM | Retention config |
Once you have this map, the automation strategy becomes obvious: each row is an API call or export you can schedule.
Step 2: Pull Evidence Directly From APIs
The core technique for SOC 2 evidence collection is scheduled API extraction. Nearly every platform that matters exposes the state you need. Below is a simplified example that captures MFA enforcement evidence from AWS IAM and writes it to an evidence bucket with a timestamp.
import boto3, json, datetime
iam = boto3.client("iam")
s3 = boto3.client("s3")
def collect_mfa_evidence(bucket: str):
users = iam.list_users()["Users"]
report = []
for u in users:
name = u["UserName"]
devices = iam.list_mfa_devices(UserName=name)["MFADevices"]
report.append({
"user": name,
"mfa_enabled": len(devices) > 0,
"device_count": len(devices),
})
ts = datetime.datetime.utcnow().strftime("%Y-%m-%dT%H-%M-%SZ")
key = f"evidence/iam-mfa/{ts}.json"
s3.put_object(
Bucket=bucket,
Key=key,
Body=json.dumps(report, indent=2),
# Object Lock enforces immutability for audit integrity
)
return key
if __name__ == "__main__":
print(collect_mfa_evidence("acme-soc2-evidence"))
Run this on a schedule (weekly is a common cadence for access evidence) and you accumulate a dated series of artifacts that prove the control operated throughout the period.
The same pattern applies to other sources:
- CloudTrail: confirm logging was never disabled with
aws cloudtrail get-trail-status - GitHub: pull merged PRs and approvals via the REST API to prove change review
- Backup jobs: query job status to show recovery capability was maintained
Step 3: Store Evidence Immutably and With Timestamps
Auditors care about integrity. If evidence could have been edited after the fact, it is weaker. Store artifacts in a location that supports write-once-read-many controls.
On AWS, S3 Object Lock in compliance mode prevents deletion or modification until a retention period expires:
aws s3api put-object-lock-configuration \
--bucket acme-soc2-evidence \
--object-lock-configuration '{
"ObjectLockEnabled": "Enabled",
"Rule": {"DefaultRetention": {"Mode": "COMPLIANCE", "Days": 400}}
}'
A 400-day retention comfortably covers a 12-month observation window plus reporting time. Combine this with:
- Timestamps in the object key and metadata so evidence is self-dating
- Versioning so any change creates a new object rather than overwriting
- Access logging so you can prove who touched the evidence store
Step 4: Schedule and Orchestrate Collection
Ad hoc scripts drift. Put collection under an orchestrator so failures are visible. A simple approach uses EventBridge to trigger Lambda functions, but any scheduler works.
# GitHub Actions: weekly evidence collection
name: soc2-evidence
on:
schedule:
- cron: "0 6 * * 1" # Every Monday 06:00 UTC
jobs:
collect:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Configure AWS
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::1234:role/soc2-evidence-collector
aws-region: us-east-1
- run: python collect_all_evidence.py
Key point: the collector should alert on failure. Missing a week of evidence creates a gap the auditor will find. Route failures to your on-call channel and treat them like any other production incident.
Step 5: Continuous Compliance, Not Point-in-Time Panic
The strategic shift here is moving from periodic scrambles to continuous compliance. When evidence is generated automatically and stored immutably, three things become possible:
- Early detection of control failures. If MFA gets disabled for an admin, your collector surfaces it in days, not at audit time.
- Faster audits. You hand the auditor a structured evidence repository instead of building it under deadline.
- Better engineering hygiene. Automating evidence forces you to codify controls, which improves your actual security posture, not just your paperwork.
This is where a broader platform view helps. Many teams standardize their control tooling and cloud guardrails as part of their overall engineering practice. If you want to see how we structure automated controls and platform engineering work, our engineering capabilities outline the delivery patterns we use. Evidence needs also vary by sector, and regulated fields carry additional obligations worth planning for early, which we cover across the industries we serve.
Common Pitfalls to Avoid
Even good automation fails when these mistakes creep in:
- Collecting state, not history. A single current export does not prove operation over time. Schedule recurring pulls.
- Sampling only happy paths. Capture exceptions too. Auditors want to see that when a control failed, you detected and remediated it.
- Hardcoding credentials in scripts. Use short-lived, role-based access for the collector itself. Your evidence pipeline should model the security you claim to have.
- No mapping to criteria. Raw logs without a control mapping force auditors to guess. Tag every artifact with the control it supports.
- Ignoring drift in scope. New systems added mid-period need coverage. Review your control matrix quarterly.
A Practical Rollout Sequence
If you are starting from scratch, sequence the work so you get value quickly:
- Weeks 1-2: Build the control matrix and identify systems of record.
- Weeks 3-4: Automate the highest-frequency, highest-risk controls first (access, change management, logging).
- Weeks 5-6: Add immutable storage, versioning, and failure alerting.
- Ongoing: Expand coverage, run a mock audit against your repository, and close gaps before the real observation window opens.
By the time your Type II period begins, evidence collection runs itself, and your team focuses on responding to real control failures rather than manufacturing screenshots.
FAQ
How often should automated SOC 2 evidence collection run?
Frequency should match the control's operation. Access and change management evidence is commonly captured weekly, while configuration state can be daily. The goal is to have enough dated artifacts that any date the auditor samples within the observation window is covered.
Can I automate all SOC 2 evidence, or is some manual work unavoidable?
Most technical controls can be automated through APIs and scheduled jobs. Certain controls that involve human judgment, such as vendor risk reviews or board oversight meetings, still require manual documentation. Automate the high-volume technical evidence and reserve manual effort for the process-based controls.
Does automating evidence collection replace a compliance auditor?
No. Automation produces higher-quality evidence and reduces preparation effort, but an independent CPA firm still performs the SOC 2 examination and issues the report. Automation makes their job faster and your report cleaner.
What is the difference between SOC 2 Type I and Type II evidence?
Type I evidence demonstrates that controls are designed appropriately at a point in time. Type II evidence demonstrates that those controls operated effectively over a period, typically 3 to 12 months, which is why continuous, timestamped collection matters so much for Type II.
How do I keep automated evidence tamper-proof for the auditor?
Store artifacts in write-once-read-many storage such as S3 Object Lock in compliance mode, enable versioning, and log all access. This proves evidence could not be altered after capture, which strengthens its reliability during the examination.
Production-grade cloud, software, and engineering teams for scaling companies.
