Field Notes · Security Leadership August 21, 2026 · 7 min read

SOC 2 is not a security strategy.

A SOC 2 report is an assurance artifact: an independent examination of defined controls, within a system boundary management chose, over a defined period. That is genuinely useful, and it is a different thing from a security strategy. Companies that treat the report as the strategy become steadily more auditable while remaining undecided about threats, architecture, and risk. This note separates what the report establishes from what it cannot, explains why the substitution happens, and lists the questions an accountable executive should ask about their own program.

What a SOC 2 report actually establishes

Precision matters here, because the argument depends on what the artifact is. SOC 2 is an attestation framework maintained by the AICPA. An independent auditor examines a service organization's controls against the Trust Services Criteria. The security category, built on the common criteria, is always in scope; availability, confidentiality, processing integrity, and privacy are included only if management chooses them. A Type I report speaks to the design of controls at a point in time. A Type II report speaks to design and operating effectiveness over a review period.

Two structural facts follow from how the framework works, and both are stated in the framework itself rather than being criticisms of it. First, management defines the system: the report covers the services, infrastructure, and boundaries described in management's own system description. Second, the criteria are assurance criteria: they exist so an independent party can evaluate whether described controls are suitably designed and operating, not so the company can determine which risks matter most to its particular business.

So a clean SOC 2 Type II establishes something real and commercially valuable: during the review period, within the described boundary, the controls management asserted were suitably designed and operated effectively against the selected criteria. Customers are right to ask for it. Companies are right to obtain it when enterprise revenue depends on it.

What it cannot establish

The same structure defines the limits. A SOC 2 report does not by itself establish:

• That the boundary is the right boundary. Systems, data flows, and subsidiaries excluded from the system description are simply not examined. The report is silent about them, and silence is not assurance.
• That the company understands its threats. The criteria include risk-assessment controls, but a company can operate a documented risk process that never seriously considers the attacks most likely to succeed against its specific architecture and business.
• That security tradeoffs are sound. Whether to build on a particular identity model, how much to invest in detection versus prevention, which vendor dependencies are acceptable: these are judgment calls outside what any attestation measures.
• That incident response works. An examined control that an incident response plan exists and is reviewed is different from an organization that knows who declares an incident, who speaks to customers, and how decisions are made under pressure.
• Anything about the future. A Type II period ends. Architecture, staff, attackers, and the product change after it.

None of this is a defect in SOC 2. It is the definition of an assurance instrument. The defect appears when the instrument is asked to do a job it was never designed to do.

Why the substitution happens

The confusion has a mechanical explanation, and it is worth naming because it operates on rational people.

Demand arrives through sales. A prospect's procurement process asks for SOC 2, so SOC 2 becomes the security goal the whole company can see. Compliance automation platforms, which are genuinely efficient at evidence collection, reinforce the framing: progress toward the audit is displayed as a percentage, and percentages get managed. The audit produces a visible, dated, externally validated artifact, while strategy produces decisions whose value is invisible until tested. Under those conditions, the audit calendar quietly becomes the security calendar, and the control list quietly becomes the roadmap.

The result is a company where the honest answer to "what is your security strategy?" is "we are SOC 2 Type II." That answer describes a report the company obtained, not a set of decisions the company made.

The consequence for the accountable executive

The gap between assurance and strategy lands on specific people. A CEO signs customer contracts whose security commitments frequently exceed the audit boundary. A GC inherits questionnaire answers and contractual representations that were written to close deals, not to be defended after an incident. A board accepts risk it has never actually seen stated. When something goes wrong in a system outside the described boundary, or through a threat the risk register never seriously modeled, the company discovers that it had been managing its evidence rather than its exposure. The report remains true, and the company is still in trouble: both things can hold at once, because the report answered a narrower question than the one the incident asks.

Questions that reveal which one you have

An executive can distinguish a strategy from an audit posture in one working session, using the company's own documents:

1. What does our report actually cover? Which trust services categories, which system description, which period? Who in leadership can answer without looking it up?
2. What is deliberately outside the boundary, and who decided that exclusion was acceptable?
3. Can leadership state the three ways this company is most likely to be seriously compromised, and does our spending have any relationship to that list?
4. Which risks have we explicitly accepted, in writing, at the executive level? If the answer is none, risk is being accepted implicitly by whoever configures systems.
5. Do our customer questionnaire answers and contractual security terms match what the audit examined, or have we represented more than we can evidence?
6. If our most likely incident happened during the last review period, would any examined control have detected it? Would the audit have even noticed the incident occurred?
7. What security work are we doing that no auditor asked for? A nonzero answer is one of the better signs that judgment, not the criteria list, is steering the program.

Companies with a real strategy answer these quickly, because the answers are decisions someone already made. Companies with an audit posture answer by referring to the report, which is the substitution making itself visible.

How sophisticated reviewers read the report

There is a practical reason the distinction matters in enterprise sales specifically: the security teams that matter most read SOC 2 reports the way the framework intends, not the way marketing implies. A capable reviewer goes past the opinion page to the parts that carry the information. They read the system description to see what was excluded. They check how subservice organizations, such as your cloud provider, are handled, because under the carve-out method those providers' controls are outside your auditor's examination. They read the complementary user entity controls, which state what the report assumes the customer does. And they read the exceptions and the review period dates, asking what has changed since.

Each of those reading habits is a probe for the same thing: where does the assurance end, and what is the company's judgment on the other side of that line. A company whose security posture is only the report has nothing on the other side of the line, and experienced reviewers notice. The strategy, where it exists, is what answers the follow-up questions.

The strongest objection

The best counterargument is that SOC 2 preparation forces real improvement: access reviews happen, offboarding tightens, logging gets deployed, policies move from folklore to documents. For an early-stage company with no security discipline at all, audit preparation is often the first structured security work it has done, and the improvement is real.

The observation is correct and does not rescue the substitution. Audit preparation raises the floor; it does not choose a direction. The criteria are common by design, because they must apply to every service organization, so they cannot encode what is unusual about your architecture, your data, your customers, or your attackers. A company can accept the floor-raising gladly and still need someone accountable for the decisions the criteria cannot make. The error is never obtaining SOC 2; the error is concluding that obtaining it settled the questions it never asked.

A second objection deserves a direct answer: "customers require it, therefore it is the strategy in revenue terms." Requirement makes it a market-access condition, like insurance or a business license. Conditions of doing business are necessary. Strategy is what a company decides beyond what everyone in the market is equally required to do.

What good looks like

In a company where the relationship is healthy, the direction of dependence is visible: the security strategy exists first, as a statement of material risks, explicit acceptances, priorities, and ownership, and the SOC 2 program is one output of it, scoped deliberately, with its limits understood by the executives who sign things. Board reporting distinguishes the two without effort: assurance status on one line, risk decisions on another. And when a customer's security team probes past the report in a review, the answers come from the strategy, which is the difference enterprise reviewers actually notice.

Conclusion

A SOC 2 report answers a defined question: were described controls, within a chosen boundary, suitably designed and operating during a period. Companies need that answer, and many need it early. A security strategy answers a different question: what can seriously hurt this company, what have we decided to do about it, and who owns those decisions. The first cannot substitute for the second, because it takes the boundary, the priorities, and the risk appetite as inputs rather than deciding them. Obtain the report. Then notice whether anyone in the company is actually answering the second question, because the audit will not tell you.

Related: When a Company Actually Needs a Fractional CISO, and When It Doesn't, on who should own the decisions the audit cannot make.

← All Field Notes