Building a SOC 2 Evidence Collector With Inngest

SOC 2 audits aren't expensive because of the auditor's fee. They're expensive because someone on your team spends 3-6 weeks pulling evidence the auditor asks for.

Most of that evidence could have been collecting itself for a year. Here's the pipeline I built for a B2B SaaS that took their last SOC 2 prep from 6 weeks to 4 days.

What evidence auditors actually want

For SOC 2 Type 2 (the common one), the auditor needs evidence that controls operated over the audit period (usually 6-12 months). The big categories:

• -**Access reviews:** quarterly evidence that someone reviewed who has access to what
• -**Vulnerability scans:** scan results, remediation timelines
• -**Change management:** evidence of code review on production changes
• -**Incident response:** evidence of incidents and how they were handled
• -**Backup tests:** evidence backups were tested
• -**Onboarding/offboarding:** evidence employees were properly onboarded and offboarded
• -**Vendor management:** vendor list, attestations from each
• -**Risk assessment:** annual risk assessment artifact
• -**Training:** evidence security training was completed by each employee

Most of these can be collected automatically from systems you already use.

The pipeline

Inngest as the orchestrator. Each evidence type has a scheduled Inngest function that collects it on a defined cadence and lands the artifact in object storage with structured metadata.

Layer 1: Access review (quarterly cron).

``` For each system (AWS, Vercel, GitHub, Linear, Slack, etc.): - Pull current user list with roles - Compare against last quarter's snapshot - Generate a diff doc showing additions / removals / role changes - Save to S3 with metadata: {control: "CC6.1", period: "Q1-2026", system: "AWS"} ```

The artifact is the diff doc, the user list, AND a sign-off entry that the responsible manager attested the access is appropriate. We collect the attestation via a Slack DM that links to the diff doc.

Layer 2: Vulnerability scan (weekly cron).

``` Run scans against production infra: - AWS Inspector for AWS resources - Snyk for dependencies - Dependabot summary for repo-level - Save scan results with metadata: {control: "CC7.1", scan_date, severity_summary} ```

Layer 3: Change management (event-driven).

``` On every GitHub push to main: - Capture commit metadata (author, reviewer, PR link) - Verify required CI checks passed - Verify the PR had at least one approving review - Land an entry in the change log artifact - Land daily summary to S3 with metadata: {control: "CC8.1", date} ```

Layer 4: Incident response (event-driven).

``` On every Sentry alert or PagerDuty incident: - Capture incident metadata - Wait 24 hours, then ask the on-call: "What was the resolution?" - Append the resolution narrative to the incident artifact - After 30 days, run a postmortem prompt that generates a draft postmortem ```

Layer 5: Onboarding/offboarding (event-driven).

``` On HR system change (Rippling, Gusto, etc.): - New hire: trigger an onboarding checklist (account creation, security training assignment, manager attestation) - Termination: trigger an offboarding checklist (account deactivation across all systems, attestation that access was removed) - Each step generates a timestamped artifact ```

Layer 6: Vendor management (monthly cron).

``` Read vendor list from a Notion database. For each vendor: - Check whether their SOC 2 attestation is in our drive and current - Check whether their DPA is on file - Flag any that are missing or expiring within 60 days ```

Where Claude helps

Claude isn't doing the evidence collection. It's doing the analysis layer on top.

Trust service criterion mapping. Each piece of evidence has metadata about which control it supports. Claude verifies the mapping is correct and flags evidence we collected that doesn't actually support the listed control.

Gap detection. Claude reads the audit framework and our evidence inventory and tells us what's missing.

Auditor-ready packaging. When the audit starts, Claude takes a list of auditor requests and produces a packaged response with the relevant evidence linked.

What the numbers look like

Before this pipeline (this company's prior SOC 2 prep): 6 weeks of work for one full-time person plus partial time from 4 other engineers. Roughly 280 hours of effort.

After: 4 days of work for one person. Roughly 30 hours. The 250 hours back was the difference between a normal sprint and a frantic one.

The audit itself completed in the same time. No findings related to evidence collection (one finding on an unrelated control).

What broke

S3 organization sprawl. Without strict naming, we ended up with evidence scattered across 3 different bucket prefixes. Half a day of cleanup to consolidate. Now there's a strict path schema enforced by a linting step.

Slack attestations got missed. The "please attest this" Slack DM sometimes got ignored. We added an Inngest scheduled function that re-pings 48 hours later, then escalates to manager after a week.

Inngest cost. At one point we had 50+ functions firing. Spend hit $400/mo. We consolidated similar functions into one with branching logic; spend went back to $80/mo.

What this isn't

This isn't a substitute for a real security program. The evidence is only as good as the underlying controls. If your access review process is "we don't really do this," the system collects evidence of you not doing it.

It also isn't a substitute for a real auditor. The auditor still needs to test controls. The system makes their testing faster, not optional.

What to build first

Access reviews and change management. These two categories are 40% of audit work and easy to automate.

Then incident response and vendor management. Both are valuable but require more system integration.

Then the rest in priority order based on which controls are biggest in your audit scope.

Total build for the basic set: 2-3 weeks. Returns: 200+ hours of audit prep saved annually.