What SOC 2 actually asks of your engineering process

Ask an engineering team what SOC 2 requires and the honest answer is usually a reference to the security or compliance function. That is the wrong place to look. SOC 2 is an audit of controls, and in a software company most of the controls it tests live in engineering: who can deploy, who can access production data, whether a change goes through review, and whether any of that is actually logged.

What SOC 2 is, precisely

SOC 2 is a report on an examination of controls at a service organization relevant to one or more of five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy, as defined by the AICPA [1]. It is not a certification and there is no pass or fail badge issued by a central authority. A licensed CPA firm examines your controls against the criteria you choose to include and issues an opinion, which is the report a customer or partner then reads.

Security is the only one of the five that every SOC 2 report must cover. The other four are added based on what you actually commit to customers: Availability if you promise an uptime SLA, Processing Integrity if you promise your system processes data completely and accurately, Confidentiality if you handle data under an obligation to keep it confidential, Privacy if you collect personal information directly from individuals. A financial software company's report should almost always include Security and Confidentiality at minimum, and often Availability.

The nine control groups behind "Security"

The Security criterion, sometimes called the Common Criteria, is organized as CC1 through CC9: the control environment, communication and information, risk assessment, monitoring activities, control activities, logical and physical access controls, system operations, change management, and risk mitigation [1]. That is the authoritative structure, published by the AICPA in the 2017 Trust Services Criteria with the 2022 Revised Points of Focus.

Translated into what an engineering team actually owns, three of the nine carry almost all of the work for a typical financial software product:

Logical and physical access controls (CC6). Who can reach production data and production systems, how that access is granted and revoked, and whether access follows least privilege. This is the same topic covered on access control and least privilege in fintech, and the overlap is not a coincidence: SOC 2's access criterion and the FTC Safeguards Rule's access requirement [2] describe the same engineering property from two different regulations.

System operations (CC7). Monitoring for anomalies, detecting and responding to security incidents, and the operational discipline around the systems that run the product. An auditor asks for evidence: alert configurations, incident tickets, response timelines, not a description of intent.

Change management (CC8). Changes to infrastructure, data, and software are authorized, tested, approved, and tracked before they reach production. This is the exact topic covered on change management and release controls, and it is usually where an AI-assisted engineering process either earns trust quickly or loses it, depending on whether AI-generated changes go through the same approval step as human-written ones.

Type 1 versus Type 2, and why it matters more than teams expect

A Type 1 report evaluates whether your controls were suitably designed as of a specific date. It answers "if these controls work as described, would they achieve the objective," and it does not test whether they actually ran that way over time.

A Type 2 report evaluates the same controls' operating effectiveness across a monitoring period, typically three to twelve months. The auditor collects evidence continuously through that window: sampled access reviews, sampled deployments, sampled incident tickets, and tests whether the control held in practice, not just on paper.

Enterprise financial buyers overwhelmingly ask for Type 2, and the reason connects directly to everything else in this hub: a Type 1 report can describe a control that existed for one afternoon around the audit date and nothing else. A Type 2 report cannot be satisfied that way, because the evidence has to exist for the whole period, which means the control has to actually be running, continuously, as part of how the team releases software rather than as a compliance exercise added just before an audit.

Where this connects to everything else in this hub

The idea that appears throughout this whole guide, that a regulatory obligation is a specification you can turn into a check, applies to SOC 2 with less translation than almost anything else here. The FTC Safeguards Rule already names secure development practices, change management, and logging of authorized user activity as explicit requirements [2]. SOC 2's CC6 through CC8 test the same properties, with an independent auditor instead of a regulator's examiner, and evidence collected over months instead of an exam sample.

Practically, that means a financial software team that has already built the checks this hub describes, an audit trail that supports re-creation, access control tied to least privilege, change management approval steps that AI-generated code cannot bypass, is most of the way to a clean Type 2 report before anyone books an auditor. The gap that remains is usually not engineering work. It is evidence collection: making sure the system produces a durable, queryable record of every access grant, every review, and every deployment, so the auditor's sample can be answered from logs rather than from memory.

If you are building or auditing that evidence trail, or preparing for a first SOC 2 examination, get in touch.