SOC 2 for Developers: The Trust Services Criteria and the Evidence Your Work Leaves Behind

By Sergey Nosov

13 October 2026

If you build software that other businesses depend on, you will probably meet SOC 2. The American Institute of Certified Public Accountants (AICPA) says that customers and business partners “often request a SOC 2 report from the service organization.” For a developer, the request shows up as rules rather than as a report. Every pull request needs an approval, production access needs a ticket, and someone reviews the access list every few months.

Those rules make more sense once you see what SOC 2 is. It is not a standard you comply with, and it is not a certificate. It is a CPA firm’s opinion on controls that your own company chose and described, judged against broad criteria from the AICPA. In a Type 2 report, the auditor also tests whether those controls worked over a period of months. Much of the evidence comes from work developers already do: pull requests, approvals, access changes, alerts, and incident records.

I do not think of these controls as checkboxes. They reflect how a team builds and operates its systems every day, and a Type 2 report checks that the practice matches the description.

What SOC 2 Is, and What It Is Not

SOC stands for System and Organization Controls; before the AICPA renamed it in 2017, it stood for service organization controls. A CPA firm performs a SOC 2 examination under the AICPA’s attestation standards, AT-C sections 105 and 205. The service organization’s management writes a description of its system, chooses the categories to cover, states its controls, and signs an assertion about them. The auditor then gives an opinion on that description, judged against the AICPA’s description criteria, and on those controls, judged against the Trust Services Criteria.

Because the result is an opinion, the vocabulary of compliance fits it poorly. In February 2026, the AICPA’s Journal of Accountancy called compliance “a term never used in SOC 2 examinations.” The opinion itself is either unmodified, often called clean, or modified: qualified, adverse, or a disclaimer of opinion.

The AICPA defines three SOC reports for service organizations:

Laws are a separate matter. The privacy criteria overlap with privacy laws on notice, consent, and people’s access to their own data. Yet the AICPA’s criteria document says that practitioners “generally do not use the trust services criteria when engaged to report on an entity’s compliance” with laws and regulations. A clean SOC 2 report is not a report on compliance with GDPR or HIPAA.

Five Categories and Thirty-Three Common Criteria

The Trust Services Criteria come from the AICPA’s Assurance Services Executive Committee. The set in use dates from 2017. A 2022 revision left the criteria unchanged and revised the points of focus, the guidance printed under each criterion. As of October 2026, there is no newer set. The criteria are sixty-one numbered statements, and reports cite them by number: CC6.1, CC8.1, A1.2. They fall into five categories that are easy to mistake for the criteria themselves. Here are the categories in the 2017 wording:

Two terms in those definitions are easy to skip and matter to developers: processing must be authorized, and personal information must be disposed of, not merely protected.

Each definition ties back to the entity’s objectives, and in a SOC 2 examination those objectives relate to meeting the company’s commitments to customers and its system requirements. The commitments usually live in contracts, service level agreements, and public statements such as a privacy notice. Availability shows why that matters: the criteria document says the availability objective “does not, in itself, set a minimum acceptable performance level.” The number comes from what the company promised, and what a promise of nines costs is the subject of Availability by the Numbers.

The categories are not five separate checklists. Thirty-three common criteria, in nine series from CC1 to CC9, apply to every category. The first five series restate the seventeen principles in the 2013 edition of the internal-control framework from COSO (the Committee of Sponsoring Organizations of the Treadway Commission). The last four, called supplemental criteria, are more operational: logical and physical access (CC6), system operations (CC7), change management (CC8), and risk mitigation (CC9).

The common criteria alone make up the security category, which is why the security criteria are part of every SOC 2 report. Each of the other four categories adds a series of its own: A for availability, PI for processing integrity, C for confidentiality, and P for privacy. The company chooses which of them to include based on its services and what its customers need.

The Criteria Do Not Name Your Controls

The most useful thing to know about the criteria is what they leave out. None of the sixty-one statements mentions passwords, multifactor authentication, encryption, a firewall, or a number of days. They say what must be true. CC6.3, for example, says the entity authorizes, modifies, or removes access “giving consideration to the concepts of least privilege and segregation of duties.” It does not say how.

Under each criterion, the AICPA prints points of focus: characteristics worth considering, such as encryption, vulnerability scans, or a process for emergency changes. They are not a checklist either. The AICPA says that using the criteria “does not require an assessment of whether each point of focus is addressed,” though a company should still consider which ones apply.

So the company designs its own controls and states them in its system description. The auditor judges whether they are suitably designed to meet the criteria and, in a Type 2, whether they operated as described. For that second test, your own words become the bar.

Suppose the description says user passwords follow the company’s policy, the policy says they expire every ninety days, and nobody configured the identity provider to enforce it. The auditor would inspect the settings, find no expiry, and report an exception against the company’s own rule. The rule is also out of step with NIST SP 800-63B-4, published in July 2025 for government systems, which says verifiers “SHALL NOT require subscribers to change passwords periodically.” The fix is to change the policy, with the approval any policy change needs, and then follow it. The new policy applies from then on; the exception already found stays in the report.

Type 1 and Type 2: A Date or a Period

A Type 1 report covers the system description and the design of the controls as of a single date. A Type 2 covers a period and adds two things: an opinion on whether the controls operated effectively throughout that period, and a detailed description of the auditor’s tests and their results. A Type 1 suits something new, with no history to test yet. For Office 365, Microsoft commissions Type 1 examinations mid-year for services launched since its last Type 2. The period of a Type 2 varies: AWS says each of its SOC 2 reports “covers the previous 12 months,” and some published reports cover only a few months.

A Type 2 is where a developer’s daily work becomes evidence. Take a control that says every production change is reviewed and approved before deployment. The auditor obtains the list of the period’s changes, checks that it is complete and accurate, and inspects a sample for the review and approval that the control promises. A list drawn only from pull requests would miss changes that never went through one.

Sampling reaches people, too, through training records, policy acknowledgments, and signed confidentiality agreements. If a control says new hires finish security training within thirty days, a sampled hire who finished on day forty-five is an exception, so finish yours on time.

Reports name the test methods: inquiry (asking people), observation, inspection of records and settings, and reperformance. A test with no deviation reads “No exceptions noted.” Other results describe an exception, such as a sampled change deployed before anyone approved it or a scheduled access review that nobody performed. Some say instead that the control went untested because nothing triggered it, as with an incident-response control in a period without incidents. A report can list several exceptions and still carry an unmodified opinion; whether they change the opinion depends on whether the auditor judges them material.

What the Criteria Ask of Developers

The criteria that reach most directly into engineering sit in the CC6, CC7, and CC8 series. Below are six areas, then two categories that apply only when a company includes them. The practices are my recommendations, not the AICPA’s; the criteria leave the how to each company.

Access

CC6.1 through CC6.3 cover logical access: who is authorized to get credentials, when credentials are removed, and how access follows “roles, responsibilities, or the system design and changes.” Request only the permissions a task needs, and give them back when it is done. Never share an account: with a shared account, the logs cannot say who did what. My Software Development Principles series has entries on least privilege and separation of duties, with the signs that each is applied well or badly.

The points of focus under CC6.1 include managing credentials for infrastructure and software. Treat service accounts, deploy keys, and API tokens as identities, each with an owner, a scope, and an end date. Keep their secrets out of source code and out of configuration files in version control.

Change Management

CC8.1 is a single sentence, and it reaches past code. The entity “authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures.” A Terraform change is a change to infrastructure. A migration is a change to data, and so is a hand-run UPDATE that fixes a customer’s records in production. A feature flag flipped in production configures software. Each needs a trail of who asked, who approved, and what changed.

The points of focus under CC8.1 include approving changes before implementation and a process for emergency changes. In practice, protect the main branch, require approval from someone other than the author, run the tests in the pipeline, and make the pipeline the only road to production. Most of the evidence then collects itself: the pull request records who wrote the change, who approved it, and which checks passed.

Make sure the approval covers the final commit and that nobody, administrators included, can merge around it except through the emergency path. Define that path in advance: who may approve an urgent change or use the bypass, how the change is tested, and who reviews it afterward. The auditor can test that path, and a quiet bypass that turns up in the sample is an exception.

Since 1 September 2026, a GitHub preview, off by default, has let Copilot submit approvals that count toward a repository’s required approvals. If the control promises approval by another engineer, a change that only Copilot approved does not meet it. For that preview, and for what a useful review looks like, see The Anatomy of a Good Code Review.

Vulnerabilities

CC7.1 asks the entity to detect “(1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.” The first half covers any configuration change that opens a hole, even one that passed review, so check infrastructure code and live settings against a written baseline. For developers, the second half is mostly the dependency tree: scan dependencies and container images, triage the findings, and fix them within the number of days your policy sets. The criteria set none, so your number is part of the control: the auditor judges its design and tests your fixes against it.

Logging and Monitoring

CC7.2 calls for monitoring system components “for anomalies that are indicative of malicious acts, natural disasters, and errors.” Many events worth watching happen in application code: sign-ins and failed sign-ins, permission and role changes, administrative actions, data exports, and changes to security settings. Log who did what, when, and from where. Keep secrets and unnecessary personal data out of the logs, and route alerts to someone who will act on them; a log nobody reads detects nothing. Threat Modeling with STRIDE shows how repudiation threats point to the actions that need records the actor cannot alter.

Data Handling

Under CC6.7, the entity restricts and protects information as it is transmitted, moved, or removed, and the points of focus under CC6.1 include encryption. When confidentiality is in scope, C1.1 and C1.2 call for identifying and maintaining confidential information and for disposing of it. For developers, deletion has to exist: a retention period that no job enforces is a rule on paper only. And production data copied into a test environment needs production care. A confidentiality point of focus under CC8.1 covers protecting confidential information during “system design, development, testing, implementation, and change processes.”

Incident Response

CC7.3 through CC7.5 follow an incident from start to finish: evaluate security events, respond through “a defined incident-response program to understand, contain, remediate, and communicate security incidents,” and recover. Know how to report a suspected incident before you need to, and know where the runbooks are. After an incident, the root-cause analysis, the follow-up fixes, and the tickets that show they were done are all evidence.

Significant incidents during the period also reach the report itself. The system description discloses those that resulted from controls not suitably designed or not operating effectively, or that caused a significant failure to meet commitments or system requirements.

Availability and Processing Integrity

Availability adds criteria for capacity management (A1.1), backups and recovery infrastructure (A1.2), and testing of recovery plan procedures (A1.3). A backup that has never been restored proves only that the backup job ran. Processing integrity adds criteria for inputs, processing, outputs, and storage. Validation at the boundary, reconciliation jobs, and safe retries belong here, since a retried payment that charges a customer twice is not accurate. Idempotency in APIs shows how to make retries safe.

Reading a Vendor’s Report

Developers sit on the other side of SOC 2, too. When your team adopts a SaaS product or a cloud service, ask for its report, even before you buy: prospective customers are among the intended readers. A Type 2 report contains the auditor’s opinion, management’s assertion, the system description, and the auditor’s tests and results. Some add a section of other information, such as management’s responses to exceptions, on which the auditor gives no opinion. Read past the first pages and check seven things:

  1. Type, period, and opinion. Is it a Type 2, and how long ago did its period end? For the months since, some vendors issue a bridge letter, also called a gap letter; Microsoft calls its own “self-attestations by Microsoft, not reports based on examinations by the auditor.” Is the opinion unmodified? If not, the report explains why.
  2. Scope. Which services, and which categories? The AWS report, for example, is the “AWS SOC 2 Security, Availability, Confidentiality, & Privacy Report”; processing integrity is not in it. Confirm that the service you use is in scope.
  3. Exceptions. Read the test results, not just the opinion: what failed, how often, and what management did about it. Ask whether any exception touches a control you rely on, and whether any such control went untested because nothing triggered it.
  4. Your responsibilities. Find the complementary user entity controls and any other user entity responsibilities: what the vendor assumes its customers do. If the vendor’s design assumes that you manage and review your own users’ accounts, and you do not, its clean opinion does not cover the gap.
  5. Subservice organizations. If the vendor runs on a cloud provider, check how the report treats it. Under what AICPA guidance calls the inclusive method, the provider’s controls are part of the same description and examination. Under the carve-out method, the report leaves them out and lists the types of controls the vendor assumes the provider performs. The vendor’s own monitoring of the provider stays in scope, but for the provider’s controls, read the provider’s report, if one exists.
  6. Incidents and changes. The description discloses significant incidents and significant changes during the period. A long list deserves questions.
  7. The auditor. SOC examinations are performed by CPAs, so the auditor should be a CPA firm. The AICPA’s peer review public file lists firms and their enrollment in its peer review program.

When the Report Comes Too Easily

That last check matters more in 2026. The February Journal of Accountancy article also reported practitioners’ concern about tool vendors that promise compliance “in mere weeks—or even just hours.” Most of those vendors “are not CPA firms,” so they cannot issue the report themselves; some have built networks of accounting firms to do the examinations. In May 2026, an AICPA alert told peer reviewers how to address the risk of engagements with “identical reports, risk assessments, sample sizes, and testing procedures.” The Journal of Accountancy article announcing it says such engagements are “not performed in accordance with the relevant professional standards in all material respects.”

None of this makes SOC 2 worthless; it makes the reading matter. In the February article, Sean Linton, chair of the AICPA’s SOC 2 Working Group, posed two questions for judging a finished report. First: “Does it seem the report is tailored to the specifics of the system being examined?” Second: “Are the controls reflective of the risks in the respective industry, and are the test procedures appropriate to the controls?”

A rushed report, the article warns, may rely too heavily on inquiry, “with the SOC examiner taking the client’s word on areas that require more thorough procedures.” In the test tables, a control tested by inquiry alone rests on the vendor’s word. And even a thorough report describes the past. In the standard language of the auditor’s report, projecting its conclusions into the future carries the risk that controls “may become inadequate because of changes in conditions.”

Checklist

Further Reading