SOC 2

SOC 2, explained for engineering teams

A SOC 2 report is the output of an attestation examination a licensed CPA firm performs under the AICPA's SSAE 18 standard (attestation section AT-C 105 and AT-C 205). It is not a certification, a licence, or a government approval, and no one "passes" SOC 2 the way you pass a test. The CPA examines whether the controls your organization says it operates are described fairly and — for a Type II report — whether they operated effectively across a window of time, then expresses a professional opinion. The deliverable is a report, typically shared under NDA with customers and their security teams, not a public badge. A vendor who tells you they are "SOC 2 certified" is using the word loosely; the accurate phrase is "we have a SOC 2 report."

The five Trust Services Criteria

SOC 2 is built on the AICPA's Trust Services Criteria (the 2017 TSC, revised in 2022). There are five categories, and only the first is mandatory:

• Security (the Common Criteria, CC1–CC9) — the baseline every SOC 2 report covers: governance, access control, change management, risk assessment, logical and physical access, system operations, and incident response.
• Availability — whether the system is available for operation and use as committed, including monitoring, capacity, and backup/recovery.
• Processing Integrity — whether processing is complete, valid, accurate, timely, and authorized.
• Confidentiality — whether information designated confidential is protected as committed.
• Privacy — whether personal information is collected, used, retained, disclosed, and disposed of in line with the organization's privacy notice.

Most engineering-led companies scope their first report to Security only, adding Availability and Confidentiality when a customer contract or risk assessment calls for them. The scope you pick decides which controls — and therefore which engineering evidence — the auditor will test. Privacy is the category most often left out of an early report because it reaches well beyond engineering into legal and data-governance commitments.

Type I versus Type II

A Type I report opines on whether your controls are suitably designed at a single point in time — a snapshot. A Type II report opines on whether those same controls operated effectively across an observation window, usually three to twelve months. Type II is the report enterprise buyers actually ask for, because design without operation proves nothing. A common path is a Type I to establish the baseline, then a Type II covering the following period; many teams skip straight to a short Type II window once their controls are stable. The length of the window is a scoping decision, not a rule.

What engineering actually owns in the audit

A large share of SOC 2 Security criteria map directly onto day-to-day engineering practice, which is why the audit lands on engineering calendars. The recurring evidence requests are concrete and system-of-record-backed:

• Change management (CC8.1) — code changes are reviewed, approved, and traceable: pull-request approvals, protected branches, and a link from a deploy back to the merge that produced it.
• Logical access (CC6.1–CC6.3) — least-privilege access to production, source control, and cloud accounts, with joiner/mover/leaver evidence and periodic access reviews.
• System operations and monitoring (CC7.1–CC7.2) — logging, alerting, and vulnerability management, with evidence that findings are triaged and remediated.
• Incident response (CC7.3–CC7.5) — a documented process plus evidence it was followed when something actually happened.
• Backup and recovery — where Availability is in scope, evidence that backups run and restores are tested.

Auditors will ask for populations and samples: every production change in the window, every new hire's access grant, every closed incident — not a tidy screenshot taken the week before fieldwork. Teams that pass cleanly are the ones whose source control, CI/CD, ticketing, and cloud providers already hold that evidence as a byproduct of normal work.

The examination lifecycle, and how it ends

A typical engagement moves through scoping (which criteria, which systems, which window), readiness (a gap assessment, often run internally or with a firm), the observation window during which controls must operate, fieldwork (the auditor requests and tests evidence), and the report. The auditor's opinion is one of four: an unqualified (clean) opinion, a qualified opinion where one or more controls had exceptions, an adverse opinion, or a disclaimer. An exception is a specific instance where a control did not operate as described; it does not automatically mean a qualified opinion, and a report with a documented, remediated exception is still a usable report. Reports also carry complementary user-entity controls (CUECs) — the things your customers must do on their side for the controls to hold.

What drives SOC 2 cost and timeline

There is no list price. The two biggest cost drivers are scope (how many Trust Services Criteria and how many systems) and the state of your controls when readiness starts — a team that already enforces reviews, access management, and logging spends far less than one building those from scratch. Beyond the CPA firm's fee, budget for the internal engineering and compliance time the evidence collection consumes, and for any readiness or automation tooling. On timeline, the floor is the observation window itself: a Type II cannot report on a three-month period until three months have elapsed. Readiness before the window and fieldwork after it each add weeks, so a first Type II commonly lands several months out even when the controls are in good shape. Treat any promise of a report in days as a Type I snapshot, not a Type II.

SOC 2 is not ISO 27001, SOC 1, or a penetration test

SOC 2 is frequently confused with neighbouring artifacts, and the distinction matters when a customer asks for "your security certification." SOC 1 covers controls relevant to a customer's financial reporting (ICFR), not security broadly — different criteria, different audience. ISO/IEC 27001 is a certification of an information security management system (ISMS) against an international standard, with a certification body and a certificate — genuinely a certification, unlike SOC 2. A penetration test is a point-in-time technical assessment, not an attestation of controls over time, though SOC 2 reports often reference that one was performed. Many controls overlap across these, which is why evidence collected for SOC 2 is reusable; the frameworks and the deliverables are not interchangeable.

Bridge letters and keeping a report current

A Type II report covers a fixed window that ends on a date in the past, so there is always a gap between the window's end and the day a customer reviews the report. A bridge letter (or gap letter) is a short statement from your management — not the auditor — affirming that no material changes to the control environment occurred between the report's end date and today. Bridge letters are a stopgap, generally accepted for a few months at most; they do not extend the auditor's opinion. The durable answer is a recurring annual (or continuous) examination so the windows abut, which is why teams invest in collecting evidence continuously rather than re-running a scramble each cycle.

This hub is operational guidance distilled from named public sources (the AICPA SSAE 18 standard and the 2017 Trust Services Criteria, revised 2022). It is not legal advice, not a determination that your organization needs SOC 2, and not a substitute for a licensed CPA firm. ShipReady does not perform SOC 2 examinations or issue SOC 2 reports.