SOC 2 Type 2

SOC 2 Type 2 is an independent examination, performed by a licensed CPA firm, of whether a service organization's controls were suitably designed and operated effectively across a stated period, commonly three to twelve months. A Type 1 report examines the same controls as of a single date, so the extra evidence in a Type 2 is operating history: samples drawn from across the period showing that each control actually ran.

That difference decides most vendor security reviews. A design opinion says a control existed on paper on one day, while a period opinion says an auditor tested the control repeatedly and reported every exception found.

Definition

SOC stands for System and Organization Controls. The framework is published by the AICPA, and a SOC 2 examination evaluates a service organization against the trust services criteria, a control set maintained by the AICPA's Assurance Services Executive Committee. Five categories exist, and each report names the ones in scope (2017 trust services criteria with 2022 revised points of focus, checked on 2026-08-13).

Security appears in every SOC 2 report. The other four categories are included when the service organization commits to them, so the phrase "SOC 2 Type 2" on its own tells a reviewer nothing about which categories were tested. The scope statement inside the report does (AICPA SOC 2 reporting guidance, checked on 2026-08-13).

What the document contains

A finished report is a bound document with a fixed shape. Five sections, in order:

Three details in the description section decide how much the report is worth to a buyer.

Complementary user entity controls, usually shortened to CUECs, are controls the report assumes the customer operates. A vendor control can only be judged effective when the customer holds up its end, so a reviewer treats the CUEC list as a set of obligations landing on their own team.

Subservice organizations are the providers the audited organization depends on, such as a cloud platform. They are handled with the carve-out method, which excludes their controls from the examination and leaves the reviewer to collect their reports separately, or the inclusive method, which pulls them into this examination.

The period ends on a fixed date. Once months have passed since that date, the vendor issues a bridge letter covering the gap, in which management states that no material control changes occurred between the period end and the letter date. A bridge letter carries management's word rather than an auditor's opinion.

Exceptions in the results section are normal and do not by themselves make a report weak. An unqualified opinion can sit alongside tested exceptions, so the useful questions are which control failed, how many samples failed, and what management changed afterwards. A qualified, adverse, or disclaimed opinion is the signal that deserves a closer read.

Example

A team wants to move its GitHub Actions jobs off GitHub-hosted runners and onto a managed fleet supplied by a third-party provider. The workflow change is one line, because the runs-on key decides which machines receive the job and its repository checkout (workflow syntax reference, checked on 2026-08-13).

name: test
on:
  pull_request:

jobs:
  unit-tests:
    runs-on: [self-hosted, linux, x64, managed-fleet]
    steps:
      - uses: actions/checkout@v4
      - run: make test

Source code, build secrets, and cache contents now pass through machines the vendor operates, so the security reviewer holds the merge until the vendor's SOC 2 Type 2 report is on file, then reads it for six answers.

The gate itself lives in the repository. A CODEOWNERS entry routes any pull request touching workflow files to the security team, and GitHub requests that review automatically, which a branch protection rule can then make a merge requirement (about code owners, checked on 2026-08-13).

/.github/workflows/  @acme/security-review

A second workflow turns the policy into a check rather than a habit. It runs on pull requests that touch workflow files and fails when a runs-on label appears that is missing from the approved list kept beside the compliance records:

name: runner-policy
on:
  pull_request:
    paths:
      - ".github/workflows/**"

permissions:
  contents: read

jobs:
  approved-labels:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/check-runner-labels.sh compliance/approved-runners.txt

The file compliance/approved-runners.txt becomes the audit trail: one line per approved label, carrying the vendor's report period and the date the review cleared it. When the period lapses, the label fails the check until someone requests the current report and clears it again.

Related Terms

• A security review checklist for GitHub Actions runners: the five questions a runner vendor review has to answer, with isolation, storage lifetime, secrets, attestation, and network boundaries in the order reviewers ask them.
• Is WarpBuild SOC 2 compliant: the attestation, the criteria in scope, and where to request the report.
• Data residency: the requirement that runner compute and cache storage sit inside a named geography, which is the question that usually follows the attestation question.
• WarpBuild security documentation: compute isolation, storage handling, and compliance posture for runners.
• WarpBuild pricing: per minute rates by runner type.