A SOC 2 Type II report attests that your security controls operated effectively over an observation window — typically 6 to 12 months — which means auditors sample real pull requests, access reviews, tickets, and alerts from that period rather than just reading your policy PDFs. That distinction trips up a lot of engineering teams. You can write a beautiful change management policy in an afternoon. You cannot retroactively make 200 merged PRs show an approval that never happened. This post walks through what auditors actually pull, which controls engineering owns, and where teams most often fail a sample.
Type I vs Type II: the window changes everything
A Type I report is a point-in-time snapshot: controls are designed correctly as of one date. A Type II report covers operating effectiveness across a window — 3 months for a first audit is common, 12 months once you're in a steady annual cycle. The practical consequence: everything your team does during the window is potential evidence. If your policy says every production change requires peer review, and in month four someone force-pushed to main with branch protection disabled "just to unblock the release," that's an exception the auditor can find. Exceptions don't automatically fail the audit, but they get written into the report your customers read.
Auditors work for a CPA firm, they test against the AICPA Trust Services Criteria (TSC), and Security (the Common Criteria, or CC series) is the only mandatory category. Availability, Confidentiality, Processing Integrity, and Privacy are opt-in.
Which Common Criteria map to engineering work
Most of the audit lands on IT and security teams, but a specific slice is engineering-owned:
| Criteria | What it covers | Typical engineering evidence |
|---|---|---|
| CC6.1–CC6.3 | Logical access, provisioning, deprovisioning | IdP group exports, offboarding tickets, quarterly access review records |
| CC6.8 | Unauthorized/malicious software | Endpoint management reports, dependency and artifact scanning |
| CC7.1 | Vulnerability detection | Scanner configs, scan schedules, findings reports |
| CC7.2–CC7.4 | Monitoring, incident response | Alert routing rules, incident tickets, postmortems |
| CC8.1 | Change management | PR approvals, CI results, deploy logs, emergency change records |
| CC9.2 | Vendor and third-party risk | Subprocessor list, vendor reviews, component inventory |
If you carry the Availability category, add A1.2 evidence: backup job logs, restore tests, and DR exercise notes with dates.
What sampling actually looks like
The auditor asks for a population, then picks samples. For change management that usually means: "Provide a system-generated list of all production changes between March 1 and August 31." They'll take 25 of your 3,000 merged PRs and ask, for each one: who authored it, who approved it, did CI pass, was the approver different from the author, and does the deploy log line up. System-generated matters — a hand-built spreadsheet invites the follow-up question of how you generated it and whether it's complete. A gh pr list --state merged --json number,author,reviews export or a direct API pull is much easier to defend.
Same pattern for access: a list of everyone terminated during the window, then proof each account was disabled within your stated SLA (24 or 72 hours, whatever your policy commits to). Pick your SLA numbers carefully, because you'll be graded against your own words.
Change management: the control engineers fail most
CC8.1 exceptions almost always come from one of three gaps. First, admin bypass: org owners who can merge without review, and do. Enable enforce_admins in branch protection or expect the sample to catch it. Second, missing emergency change process: hotfixes happen, and that's fine — but your policy needs a documented emergency path (post-hoc review within N days, ticket linking the incident), otherwise every hotfix is an exception. Third, infrastructure drift: Terraform applied from a laptop instead of the pipeline leaves no reviewable trail. Route terraform apply through CI with plan output attached to the PR, and the evidence generates itself.
A dry aside: auditors have seen the "we disabled branch protection for one afternoon" story roughly a thousand times. The audit log remembers the afternoon.
Vulnerability management and dependency evidence
CC7.1 testing has gotten more specific about third-party code. Expect requests for: your scanning tool configuration, proof scans ran on schedule for the whole window, and tickets showing findings were remediated within your defined SLAs (commonly 15 or 30 days for critical, 90 for high). Gaps in scan history — the six weeks the scanner license lapsed — show up as exceptions. Continuous software composition analysis makes this one of the easier controls to evidence, because every scan result is timestamped and every fix maps to a PR. Teams running Safeguard typically export findings-to-remediation reports directly rather than screenshotting dashboards, which auditors prefer anyway.
Don't forget the inverse case: findings you decided not to fix need documented risk acceptance with an owner and a date, not a silent "won't fix" label.
How to prepare without making it a second job
Three things reduce audit pain more than anything else. One: automate evidence collection early — API-pulled, timestamped exports beat screenshots, and compliance platforms or a cron job hitting the GitHub and IdP APIs both work. Two: run an internal sample yourself at the window's midpoint; pull 10 random PRs and 5 offboardings and check them against your own policy before the auditor does. Three: train the team on what triggers exceptions, because a single well-meaning bypass costs more explanation time than an hour of prevention. If your team is new to audit mechanics, the Safeguard Academy has a compliance track that covers evidence design for engineers.
Frequently asked questions
How long is a SOC 2 Type II observation window?
Commonly 3, 6, or 12 months. First-time audits often use 3 months to get a report in customers' hands quickly, then move to an annual 12-month cycle so there are no coverage gaps between reports.
Do auditors read our actual code?
No. SOC 2 tests the controls around your development process — reviews, approvals, scanning, access — not code quality itself. The closest they get is verifying that a code review happened and that scan findings were triaged.
What happens if a control fails during the window?
The auditor documents it as an exception, and management gets to include a response describing remediation. A handful of explained exceptions is normal; a qualified opinion only happens when failures are pervasive enough that the control objective wasn't met.
Which SOC 2 controls cover open source dependencies?
CC6.8 (unauthorized software) and CC7.1 (vulnerability detection) are the usual homes, sometimes with CC9.2 for vendor risk. Auditors increasingly expect dependency scanning with SLAs and a component inventory, not just infrastructure scans.