The word “control” gets thrown around in SOC 2 conversations as if it means one thing — usually “whatever the auditor is asking about this week.” That looseness is expensive, because a SOC 2 report is not a certification and controls are not the criteria. The Trust Service Criteria describe what has to be true; controls are how a company makes it true, and how it proves that to an auditor. Every control a business puts in place for SOC 2 sorts into one of three families — logical, physical, and administrative — and most audit findings trace back to one family being funded while the other two were assumed to take care of themselves.
Controls vs Criteria — What vs How
SOC 2 is an attestation, not a badge. It is issued under SSAE 18 — the AICPA’s attestation standard — by a licensed CPA firm, which examines a company’s controls and renders an opinion on them. Nobody “passes” SOC 2 the way a product certifies to a technical spec; the auditor is testing a claim, and that claim is built from two layers that get conflated constantly.
The criteria describe the promise
The Trust Service Criteria — Security, and optionally Availability, Confidentiality, Processing Integrity, and Privacy — describe outcomes a company is promising to uphold. Security (the Common Criteria, CC1 through CC9) is mandatory in every SOC 2 report; the other four are selected based on what the company actually promises customers. The criteria never say “buy this firewall” or “write this policy.” They say things like: access to production systems is restricted to authorized personnel, and changes to the environment are approved before deployment.
Controls describe how the promise gets kept
Controls are the actual practices, technologies, and procedures a company puts in place to satisfy those promises — and to leave a trail proving it. A single criterion is rarely satisfied by one control; it is usually satisfied by several, pulled from different families. That is the part teams miss when they treat “control” and “criterion” as interchangeable: the criteria are fixed by the framework, but the controls that satisfy them are chosen by the company, and choosing them well is most of the actual work of getting audit-ready.
Logical (Technical) Controls
Logical controls are the ones most companies picture first when they hear “SOC 2 controls,” because they live in tooling engineers already touch every day. They govern who — and what — can reach a system, and what happens once they’re inside.
- Access control — role-based permissions, least-privilege provisioning, and prompt de-provisioning when someone leaves or changes roles
- Multi-factor authentication — required on production systems, admin consoles, and anything holding customer data
- Encryption — data encrypted in transit (TLS) and at rest, with key management that doesn’t leave keys sitting next to the data they protect
- Logging and monitoring — centralized logs, alerting on anomalous activity, and someone actually reviewing what the alerts surface
- Vulnerability management — regular scanning, a defined patching cadence, and evidence that findings get remediated rather than triaged into a backlog forever
- Network segmentation — separating production from development, and limiting lateral movement if one segment is compromised
These are the controls that map most directly onto CC6 (Logical and Physical Access Controls) and CC7 (System Operations) in the Common Criteria. They are also, not coincidentally, the controls that show up first in every vendor security questionnaire — which is exactly why they get funded first and audited hardest. The risk isn’t that logical controls are wrong to prioritize. It’s that a company can nail every item on this list and still fail an audit, because two other families are being tested at the same time.
Physical Controls
Physical controls protect the actual hardware — the data center floor, the server racks, the network equipment sitting in a building somewhere. They cover badge access, visitor logs, security cameras, and environmental protections like fire suppression, temperature control, and redundant power.
For a company running its own data center, these controls are tested directly: an auditor might review badge logs or walk the facility. For the overwhelming majority of SaaS companies — running entirely on AWS, Azure, or Google Cloud — there is no facility to walk, because the servers were never theirs. This is where the shared responsibility model matters most: the cloud provider owns the physical security of the hardware, and the company inherits that control rather than building it.
Carve-out vs. inclusive
Auditors handle this inheritance one of two ways. Under the carve-out method — the far more common approach — the cloud provider’s controls are excluded from the scope of the company’s own SOC 2 opinion, and the company instead relies on the provider’s own SOC 2 report to cover that ground. Under the inclusive method, the subservice organization’s controls are tested directly as part of the same engagement, which is rare and usually reserved for smaller or less-established providers. Almost every cloud-hosted company uses carve-out.
Inheriting physical security doesn’t mean the responsibility disappears — it moves. A company still has to obtain and review its cloud provider’s SOC 2 report annually, confirm the provider’s controls actually cover what the company is relying on, and document that review. Skipping that step is one of the more common gaps auditors flag, because “we’re on AWS” is not, by itself, evidence of anything.
Inheriting a control from a cloud provider still requires the company to prove it did the inheriting correctly — pulling the provider’s report, checking its scope and exceptions, and keeping that review on file. An auditor testing CC6 wants to see the review, not just the assumption that “the cloud provider handles it.”
Administrative (Organizational) Controls
Administrative controls are the least glamorous of the three families and the most heavily tested, because they are the evidence that a company runs a real process rather than reacting to whatever comes up.
- Policies — a written security policy, access control policy, incident response plan, and the handful of others the Trust Service Criteria expect to exist and be followed, not just filed
- Security-awareness training — delivered to every employee, tracked, and repeated on a cadence, not a one-time onboarding video nobody remembers
- Access reviews — periodic recertification of who has access to what, catching the permissions that should have been revoked months ago
- Onboarding and offboarding procedures — documented steps for granting access when someone joins and revoking it, same day, when they leave
- Vendor management — a process for evaluating and monitoring third parties, including reviewing their own SOC 2 reports where relevant
- Incident response — a documented plan, tested through at least an occasional tabletop exercise, not written once and left in a drawer
None of these require a purchase order. That is precisely why they’re easy to under-invest in: there’s no vendor pushing a renewal, no dashboard showing a red badge, until an auditor asks for evidence and the company realizes the policy was never actually approved, or the last access review was eighteen months ago. Administrative controls are where “we do this” and “we can prove we did this” diverge most often — and an auditor only credits the second one.
How the Three Families Combine
No single criterion in a SOC 2 report is satisfied by one family alone. Take CC6.1 — logical access to systems is restricted to authorized users. On paper it sounds purely technical. In practice, satisfying it takes all three families working together: a technical control enforcing the restriction (MFA, role-based access), an administrative process governing how access gets granted and reviewed (an access control policy, a quarterly recertification), and — for anything cloud-hosted — an inherited physical control confirming that the underlying infrastructure is itself only reachable by authorized personnel at the provider.
That overlap is the actual shape of a SOC 2 control environment: not three separate silos, but three layers stacked under almost every promise the report makes.
| Control family | Examples | Typical evidence |
|---|---|---|
| Logical (technical) | Access control, MFA, encryption, logging & monitoring, vulnerability management, network segmentation | Access logs, MFA enforcement configs, encryption settings, scan reports, alert tickets |
| Physical | Facility security, badge access, environmental controls — largely inherited from the cloud provider | Provider’s SOC 2 report, vendor review notes, data center certifications |
| Administrative (organizational) | Policies, security-awareness training, access reviews, onboarding/offboarding, vendor management, incident response | Signed policies, training completion records, access review sign-offs, IR tabletop notes |
An auditor sampling CC6.1 will typically ask for evidence from at least two of these three rows, sometimes all three. Preparing for only the top row — the part that feels the most “security engineering” — is the single most common way companies walk into an audit under-prepared.
The Common Imbalance
Ask most engineering-led companies to describe their SOC 2 controls, and they’ll start with MFA, encryption, and monitoring — the logical family — and stop there, or mention physical security almost as an afterthought (“we’re on AWS, so that’s covered”). Administrative controls barely make the list, even though they are frequently where audits stall.
The instinct isn’t irrational. Technical controls are the ones engineers already own, they’re visible in a dashboard, and they can be stood up with a purchase and a config change. Administrative controls require writing things down, running training nobody asks for, and reviewing access on a schedule when there’s always something more urgent to ship. It’s the same bias that shows up in the preventive-versus-detective-versus-corrective lens on controls: it’s easy to buy preventive tooling, harder to build the detective habit of actually reviewing what that tooling surfaces, and harder still to close the loop with a corrective process every time.
The compromise of SolarWinds’ Orion software, disclosed in late 2020, is a useful reminder of where the gap tends to open. Attackers inserted malicious code into a routine software update, and the intrusion sat undetected for months. The failure wasn’t a missing firewall — it was the harder, less visible layer: detective monitoring that didn’t catch what preventive tooling let through, and the organizational discipline to keep watching a trusted vendor’s software rather than assuming trust, once granted, doesn’t need revisiting. Strong logical controls on their own don’t catch that. Administrative process — vendor oversight, continuous review — is what’s built to.
The fix isn’t abandoning technical investment; it’s treating all three families as one budget, not three separate ones, and asking honestly which family last got a real review.
Final Thought
SOC 2 controls aren’t a shopping list of tools to buy or a single team’s responsibility. They’re three families — logical, physical, administrative — that together make up the control environment an auditor is actually testing, and a report only holds together when all three are funded and evidenced, not just the one that felt the most urgent to fix first.
The test worth running before an audit ever starts: for each Trust Service Criterion the report will cover, can the company point to a technical control, a written process, and a review that confirms both are still true? If the answer stops at the first one, the gap won’t show up in engineering — it’ll show up in the auditor’s request list.
Frequently Asked Questions
SOC 2 controls are the practices, technologies, and procedures a company puts in place to satisfy the Trust Service Criteria — the outcomes a SOC 2 report promises to uphold. They sort into three families: logical (technical) controls like access management and encryption, physical controls covering facility and infrastructure security, and administrative controls like policies, training, and access reviews.
No. SOC 2 is an attestation report issued under SSAE 18 by a licensed CPA firm, not a certification a company earns once and holds forever. The auditor examines a company’s controls and issues an opinion on whether they’re suitably designed (Type I) or designed and operating effectively over a period (Type II). Controls are the evidence behind that opinion — not a checklist a company checks off to “pass.”
Logical controls include role-based access control and least-privilege provisioning, multi-factor authentication on production and admin systems, encryption in transit and at rest, centralized logging and monitoring with active alert review, regular vulnerability scanning with a defined patching cadence, and network segmentation between production and development environments.
Most physical controls are inherited from the cloud provider rather than built by the company, since the provider owns the data center. Under the common carve-out method, the provider’s physical controls are excluded from the company’s own SOC 2 scope and covered instead by the provider’s own SOC 2 report. The company’s job shifts to reviewing that report annually and documenting the review — inheriting a control doesn’t remove the responsibility to verify it.
The Trust Service Criteria describe what has to be true — for example, that access to production systems is restricted to authorized personnel. Controls describe how a company makes that true and proves it: the specific technical settings, written policies, and review processes it implements. A single criterion is usually satisfied by several controls pulled from more than one family, not one control mapped one-to-one to one criterion.