Almost every cyber submission above the small commercial threshold arrives with a SOC 2 Type II. Most underwriters give it ten minutes, read the auditor's opinion, glance at the period, note the issuing firm, and move to the next document. That is a missed signal.
The control-by-control body of a SOC 2 is the most evidentiary document in the submission. It is the only place an underwriter can see, in writing, what the insured's controls are, who tested them, whether they were operating effectively, and what exceptions came up. This piece is how to read it the way a senior underwriter reads it.
The auditor opinion tells you the test was done. The control-by-control body tells you what was actually found.
1. Read the scope first
Before any control content matters, you have to understand what the report covers. Look for:
- Trust Services Criteria. Security is the baseline. Availability, Confidentiality, Processing Integrity, and Privacy are added optionally. A SOC 2 with only the Security criterion is not the same as a SOC 2 with all five.
- System scope. Which products, environments, and business units are in scope. A SOC 2 that covers a marketing website and not the production trading platform is informative but does not underwrite the platform.
- Audit period. Type II is an over-time examination. A six-month period is acceptable for a first report. A twelve-month period is the steady state. Anything shorter deserves a question to the broker.
2. Identify carve-outs and subservice organizations
If the insured runs on AWS, Google Cloud, or any hosted infrastructure, the SOC 2 will treat that subservice organization as either "carved out" (excluded from the report scope) or "inclusive" (covered by the same audit). Carve-outs are normal. They mean the insured is relying on the subservice provider to operate certain controls, and that provider has its own SOC 2 the insured monitors.
Underwriting question: does the insured's vendor management process actually receive and review the subservice provider's SOC 2 reports each year. If yes, the carve-out is a control. If the broker cannot show that process, it is a gap.
3. Map controls to your appetite, not the auditor's framework
A SOC 2 organizes controls under the AICPA Common Criteria (CC1 through CC9). Your underwriting appetite organizes them under your own rubric: identity and access, data protection, vulnerability management, incident response, third party risk. The work is mapping one to the other.
A short example. The application asks "does the insured enforce MFA on privileged accounts." The insured answers yes. The SOC 2 control description in CC6.1 says: "Multi-factor authentication is required for all administrative access to in-scope systems." The test of operating effectiveness in the same section says: "A sample of 25 privileged users was tested, all 25 had MFA enforced during the audit period." That is a complete chain of evidence, cited to a specific page. The application answer is now grounded.
4. Read the exceptions section like a leading indicator
Exceptions are where every honest report has a few. The patterns to pay attention to:
- Single isolated exception in one control.Common. Usually fine. Note management response and move on.
- Repeated exceptions in the same control across periods.Pattern of unresolved weakness. Worth raising with the broker.
- Exceptions concentrated in identity and access controls.Strong leading indicator of ransomware exposure. Not a decline by itself, but a reason to ask for additional supplementals.
- Exceptions noted in change management or vulnerability management. The two control families most predictive of breach in the carriers we speak to. Treat seriously.
5. Cross-reference against the application, every time
The single highest-value thing to do with a SOC 2 is reconcile it against the application. Every controls answer in the application is a claim. Every relevant SOC 2 control is evidence. Build a small table in the memo:
- Application claim, with citation.
- SOC 2 control reference, with citation.
- Status: confirmed, partially confirmed, contradicted, or not addressed.
Contradictions are the most important. An application that claims "EDR deployed across all production endpoints" against a SOC 2 that scopes EDR to a subset of the environment is a question for the broker. It is also exactly the kind of finding a regulator or claims handler will look for if a loss happens.
What Hugo does with this
Hugo reads the SOC 2 in full, control by control, and produces the cross-reference table automatically with citations. Underwriters get a memo that maps every applicable control to the carrier's appetite, flags exceptions, and surfaces contradictions against the application. The work that takes a senior underwriter two hours becomes a five minute review.
Frequently asked
Questions readers ask
- How is a SOC 2 different from ISO 27001 for underwriting?
- ISO 27001 certifies a management system. SOC 2 attests to specific controls and tests their operating effectiveness over a period. Both are useful, but SOC 2 Type II is more directly mappable to underwriting questions because the control-by-control evidence is in writing. We accept ISO certificates as supporting evidence and SOC 2 Type II as primary evidence.
- What if the insured only has a SOC 2 Type I?
- Type I is a point-in-time design assessment. It says the controls were defined, not that they operated. We treat it as a partial signal and ask for either a Type II by renewal or a supplemental that bridges the gap. We do not refuse to quote on Type I alone, but we do price for the lower confidence.
- Does Hugo only handle SOC 2, or other frameworks too?
- Hugo reads SOC 2, ISO 27001 statements of applicability, HITRUST, PCI DSS attestations, and FedRAMP packages where they apply. The methodology is the same: map declared controls to the carrier's appetite, ground each conclusion in a citable source, surface contradictions against the application.