About half the SOC 2 prep work I see in health tech is wasted because the team is collecting the wrong evidence. They're taking screenshots of AWS console settings, exporting CSVs of IAM users, pasting Slack approvals into a Notion page. Then the auditor rejects the package, and they're scrambling three weeks before the audit window closes.
Here's what auditors actually want, control by control, for the AWS portion of a SOC 2 Type II audit.
Access reviews (CC6.1, CC6.2, CC6.3). Not a screenshot of IAM. Auditors want a quarterly access review report that shows every IAM user, every role, every group membership, who reviewed it, what changes were made, and the date. The accepted format is a CSV or PDF generated from IAM Access Analyzer findings plus a signed reviewer certification. Set up a quarterly Lambda job that exports this to S3, have your designated reviewer sign off in writing, and keep both the data and the signoff. Slack approvals are not signoffs.
Change management (CC8.1). Auditors want to trace a sample of production changes from ticket to PR to review to deploy to post-deploy verification. The common gap: teams have great Linear or Jira tickets and great GitHub PRs, but no link between them. Add the ticket ID to the PR title as a hard convention. Export from GitHub via API quarterly. The evidence package is the ticket, the PR with reviewer name, the deploy log from CI showing timestamp and commit SHA, and a post-deploy check. A test run, a monitoring alert resolution, anything time-stamped.
Logging and monitoring (CC7.2, CC7.3). What auditors reject: "we use Datadog." What they accept: a documented list of which security events generate alerts, the alert configuration showing the trigger logic, the on-call rotation policy, and a log of three to five sample alerts from the audit period showing they fired, were acknowledged, and were resolved. The sample evidence is the part most teams forget.
Backup and recovery (A1.2). Not "we have automated RDS snapshots." Auditors want a documented RPO and RTO, evidence that backups completed during the audit period (CloudWatch metrics or AWS Backup reports), and evidence of a tested restore. This is the one that catches teams. Yes, you have to actually restore a backup at least once during the audit period and document the test. Most teams skip this and fail the control.
Vulnerability management (CC7.1). Inspector findings exported quarterly with documented remediation timelines. Critical: seven days. High: 30 days. Medium: 90 days. Plus evidence that remediations happened within those windows. The evidence is the Inspector report at start of period, the Inspector report at end of period, and tickets showing remediation work.
The pattern across all of these: auditors want a process artifact, not a configuration artifact. A screenshot proves the control existed at one moment. A quarterly report with a reviewer signature proves the control operated continuously. SOC 2 Type II is about operating effectiveness over time, not point-in-time existence.
If you're heading into your first SOC 2 audit and your evidence collection is mostly screenshots and Slack threads, the 2-week Transivone audit includes a SOC 2 evidence gap assessment. What you have, what auditors will reject, and exactly what to build before the audit window opens.
— Manan