Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
How do you prepare engineering teams for SOC 2?
Last verifiedTranslate the criteria into habits your team already half has: every production change independently approved, access granted and removed through a tracked path, secrets out of repositories, logs and alerts someone triages, backups tested, incidents ticketed with a review. The evidence is a by-product of doing it properly.
Preparing engineering teams for SOC 2, last verified 10 September 2026 against the AICPA Trust Services Criteria (TSP section 100 — 2017 criteria with the 2022 revised points of focus) and the AICPA attestation standards SSAE 18, AT-C sections 105 and 205. SOC 2 is an attestation examination performed by a licensed CPA firm and delivered as an opinion — a report, not a certification. This page is not legal advice, does not determine that YOU need SOC 2, and does not issue a SOC 2 report.
This is the engineering translation, not YOUR control set
Audience: an engineering manager, staff engineer, or DevOps lead who has been told SOC 2 is happening and wants to know what changes in day-to-day work. This page translates criteria subject areas into engineering habits. It does not determine that YOU need SOC 2, does not choose your controls, and does not issue a SOC 2 report.
The Trust Services Criteria are proprietary AICPA material. This page cites criteria series references — CC1 through CC9 — and paraphrases subject areas in our own words; the licensed criterion text is never reproduced. Your controls are yours to choose, and the practitioner tests the controls you describe, not the ones on this page.
SOC 2 is market and contractual, not statutory: no statute requires a SOC 2 report, so nothing here is a legal obligation on an engineer. "SOC 2 certified" is a misnomer — there is no SOC 2 certificate, and nobody is coming to certify your pipeline. Type I addresses the design of controls at a point in time; Type II addresses operating effectiveness over a review period, which is why engineering habits matter more than engineering documents. Only a licensed CPA firm can perform a SOC 2 examination and issue the report; compliance-automation tooling, including this product, is not the attestor. Last verified 10 September 2026. Not legal advice.
Criteria in engineering language
Each row: the subject area, the habit, the artefact it leaves behind, and whether the examination tests it or it is simply good practice.
| Area | The habit | The artefact it leaves | Tested, or good practice? |
|---|---|---|---|
| Change management (CC8) | Every production change goes through a pull request approved by someone other than the author, with tests run in the pipeline. Infrastructure changes get the same treatment. Emergency changes use a documented path and get reviewed afterwards. | Pull requests with reviewer identity and timestamp, pipeline runs, deployment records, the complete change population for the period. | Tested — this is one of the highest-volume sampled areas. Trust Services Criteria reference CC8. |
| Access provisioning (CC6) | Access requested and granted through a tracked path, not a message. Role-based where possible, least privilege by default, single sign-on and multi-factor authentication for in-scope systems. | Provisioning tickets with requester, approver, and timestamp; group membership history; authentication configuration. | Tested. Trust Services Criteria reference CC6. |
| Deprovisioning (CC6) | When someone leaves or changes role, access is removed within your stated timeframe — including cloud consoles, repositories, production databases, and long-lived tokens. | Removal records with timestamps for every account and system, tied to the termination date. | Tested, and the single most common source of exceptions. Trust Services Criteria reference CC6. |
| Access reviews (CC6) | Someone with authority reviews who has access to what, at the cadence your policy states, and actually removes what is not needed. | Completed review records with reviewer name, date, and the changes that resulted. | Tested. A review with no resulting changes and no evidence of examination invites questions. Trust Services Criteria reference CC6. |
| Secrets handling (CC6) | No credentials in repositories, secret scanning enabled, secrets in a manager with rotation, and a documented response when one leaks. | Secret-scanning findings with resolution, rotation records, the incident ticket for any leak. | Tested where you describe it as a control; the specific tooling choice is good practice. |
| Logging and monitoring (CC7) | Security-relevant events logged, retained for a stated period, alerting configured, and someone triaging alerts as work rather than noise. | Alert samples with disposition, retention configuration, on-call records. | Tested. Trust Services Criteria reference CC7. |
| Vulnerability management (CC7) | Dependency and code scanning running continuously, findings triaged by severity, and remediation inside stated target timeframes. | Findings with severity, owner, and remediation date across the whole period. | Tested where described; the specific timeframes are yours to set, and the examination tests whether you met your own. |
| Backups and recovery (A series if in scope) | Backups running, restores actually tested rather than assumed, and recovery objectives written down. | Backup job records, restore test results with dates. | Tested only if the Availability category is in scope; otherwise good practice you should still do. |
| Incident response (CC7) | Incidents ticketed with a timeline, roles known before the incident, and a post-incident review that produces actions. | Incident tickets, timeline, post-incident review documents, evidence the plan was exercised during the period. | Tested. Trust Services Criteria reference CC7. |
| Onboarding and training (CC1) | New engineers acknowledge policies and complete security training; the record exists per person. | Acknowledgement and training completion records with dates. | Tested. Trust Services Criteria reference CC1. |
Developer and DevOps checklist
The version to paste into a team channel. Short, concrete, and labelled so nobody thinks a preference is a requirement.
- Branch protection on: no direct pushes to the deployed branch, approval required from someone other than the author. Tested area — Trust Services Criteria reference CC8.
- Emergency-change path written down, and used rather than bypassed, with an after-the-fact review. Tested area.
- Every production change traceable to a pull request or ticket — including infrastructure and configuration. Tested area.
- Access requests go through the tracked path even when the requester is a founder. Tested area — Trust Services Criteria reference CC6.
- Offboarding runbook covering every system, including long-lived tokens, service accounts, and third-party tools. Tested area, and the top exception source.
- Secret scanning enabled and findings actually closed. Tested where described as a control.
- Dependency findings triaged with owners and target dates. Tested where described.
- Alerts routed to a human who owns them during their shift. Tested area — Trust Services Criteria reference CC7.
- Restore tested, not just backup configured. Good practice; tested only if Availability is in scope.
- Post-incident reviews written, with actions that get done. Tested area.
- Infrastructure as code, small pull requests, trunk-based development, and a tidy service catalogue: good engineering practice that makes evidence easier, none of it required by any attestation standard.
What engineers should stop worrying about
Half the anxiety around a first examination is about things that are not tested. Naming them buys back goodwill.
- Nobody reads your code for style. The examination tests controls, not code quality.
- No specific tool is required. There is no mandated ticketing system, cloud provider, scanner, or platform — including this one.
- There is no mandated deployment frequency, branching model, or test-coverage number. If someone tells you a percentage is required by SOC 2, they are inventing it.
- The auditor is not looking for perfection. Exceptions are common and survivable; concealment is not.
- You do not need to freeze releases during fieldwork. You need to be able to produce the complete change population.
- Documentation for its own sake is not the goal. A policy nobody follows is worse than no policy, because it manufactures its own exception.
Kinds of text on this page
Different sentences here carry different weight. The table labels which is which, so no engineering preference gets presented to an auditor as an obligation.
| Kind of text | What it means | What it is not |
|---|---|---|
| Attestation-standard requirement | SSAE 18 — AT-C sections 105 and 205 — governs how the CPA firm plans, performs, and reports the examination. | Not a statute, and it mandates no tool, cadence, or engineering practice. |
| Trust Services Criteria reference | A pointer to a criteria series (CC1–CC9 or an optional category) in TSP section 100. | Not the criterion text. The Trust Services Criteria are proprietary AICPA material; every description here is paraphrase. |
| Best practice | Good engineering that makes evidence easier — small changes, infrastructure as code, tidy runbooks. | Not required by any attestation standard. Skipping it is not an exception. |
| Market observation | What teams commonly find hardest, such as offboarding completeness. | Not a rule, and not a prediction about YOUR engagement. |
| SRM recommendation | Something this product suggests doing. | Not a legal requirement, not an attestation requirement, and not an audit opinion. |
What to do now
Two weeks of unglamorous work removes most of the exception risk an engineering team owns.
- Turn on branch protection with required review by someone other than the author, on every deployed repository, today.
- Write the offboarding runbook by walking one real departure and listing every system where access existed.
- Find the paths that bypass the pipeline — manual deploys, console changes, direct database edits — and either close them or make them produce records.
- Check that access reviews will produce evidence: who reviews, on what cadence, and where the record lands.
- Enable secret scanning and dependency scanning if they are not on, and assign the findings to owners rather than a queue nobody reads.
- Confirm alerting reaches a human, and that the human knows they own it.
- Run one restore test and write down what happened, even if Availability is out of scope.
- Ask the compliance owner which criteria categories are in scope, so you are not building for a category nobody bought.
Checklist
The compressed engineering list, labelled by kind of text. Not an audit programme.
- Independent approval enforced on every production change, including infrastructure? Trust Services Criteria reference CC8.
- Complete change population producible from a system of record? Attestation-standard requirement for completeness.
- Offboarding runbook covers every system, tokens and service accounts included? Trust Services Criteria reference CC6.
- Access reviews produce dated records with named reviewers? Trust Services Criteria reference CC6.
- Secret and dependency findings owned and closed with dates? Trust Services Criteria reference CC7 where described.
- Alerts triaged by a named human? Trust Services Criteria reference CC7.
- Incidents ticketed with timeline and post-incident review? Trust Services Criteria reference CC7.
- Policies match what the team actually does? Best practice — mismatch manufactures exceptions.
- Nobody enforcing an invented rule about coverage percentages or deployment cadence? Attestation-standard requirement mandates none of it.
Where this shows up in ShipReady Metrics
The bundled framework key soc2 is customer-visible, labelled against the 2017 Trust Services Criteria with the 2022 revised points of focus, with a starter control-set that is an illustrative readiness mapping to be tailored by a compliance owner.
If you already have a session: this is the part of the cluster where connector-sourced evidence does real work. Dependency findings, code-scanning results, and secret-scanning results ingest continuously with their own timestamps, which is exactly the shape of evidence the CC7 rows need across a period. Evidence collection holds the rest, and evidence review with the met-verdict overlay records a named human's judgement per control. Engineering metrics in this product — delivery metrics and per-committer metering, including the AI-authored-code view — are engineering-governance signal, not attestation evidence and not a criterion; do not present them to a practitioner as a control. The policies library holds the documents engineers get asked to acknowledge. The cyber risk register lives under the security area.
Readiness in this product is not an attestation opinion. This product does not issue a SOC 2 report and does not replace a licensed CPA examination. There is no public SOC 2 demo URL.
Primary sources (last verified 10 September 2026)
Criteria series references come from TSP section 100, paraphrased because the criterion text is licensed. Engineering practices labelled best practice are ours, not the AICPA's.
AICPA Trust Services Criteria, TSP section 100 — 2017 criteria with the 2022 revised points of focus, including the common criteria series CC1 through CC9 and the optional categories. Proprietary AICPA material: cited by reference and paraphrased, never reproduced. AICPA attestation standards SSAE 18, AT-C sections 105 and 205. AICPA SOC 2 guidance for service organisations. These are not a complete list, and none of them is legal advice.
The SOC 2 framework guide on this site is the education page under frameworks; this cluster does not reuse that slug. The SOC 2 readiness checklist template on this site is live. The SOC 2 versus ISO 27001 comparison on this site is live. A dedicated ISO 27001 docs cluster is not on this site yet — naming ISO 27001 in prose is not a link to it.