SOC 2 and data handling for AI fraud investigation: what enterprises require

An AI vendor security review in insurance starts where most SOC 2 conversations end. When a CIO at a top-25 P&C carrier opens the file on an AI claims-investigation vendor, the first question is rarely "do you have SOC 2." It is "what is scoped in your SOC 2, what does your data-handling addendum say, and where in your architecture does our nonpublic information sit." SOC 2 compliance is the floor. The ceiling is built control by control on top of it.

The stakes now carry third-party numbers. IBM's Cost of a Data Breach Report 2025 puts the average US breach at $10.22 million, the highest of any country it measures, and finds that incidents involving unsanctioned "shadow AI" add roughly $670,000 to the bill. Verizon's 2026 Data Breach Investigations Report ties nearly half of breaches (48%) to third-party involvement. An AI investigation vendor is exactly that third party, and it touches the most sensitive data a carrier holds - claim files, medical records, and the nonpublic information state regulators expect the carrier, not the vendor, to answer for within 72 hours.

This post is for Priya, the Carrier CIO who reviews after the SIU Director has championed and the CFO has nodded - quickly, in days, but with a hard veto if anything is off. It defines what a SOC 2 report actually attests to under the AICPA Trust Services Criteria, shows how to read and verify the report itself (exceptions, CUECs, subservice organizations, bridge letters), lists the seven data-handling controls to verify beyond the report, maps everything to NAIC Model #668 and NYDFS 23 NYCRR 500, and ends with a procurement-ready checklist she can hand to a vendor before the security-review meeting.

The frame around the procurement is hardening fast. The NYDFS Second Amendment to 23 NYCRR 500 took effect November 1, 2023, and the NAIC Insurance Data Security Model Law (Model #668) has now been enacted in 28 jurisdictions per NAIC's August 2025 count, more than most vendor guides still report. The carrier is regulated; the AI vendor sits inside that regulation as a third-party service provider. For the broader vendor frame around this security review, see our guide to autonomous AI claims investigation and the parallel Claims VP deployment playbook.

Priya is reviewing the vendor for a specific reason. The SIU is the bottleneck. Manual investigation takes 14+ days per case, the team covers only ~25% of flagged claims, and the board has noticed. The AI vendor closes that gap by running investigations in minutes and lifting coverage to 100% of flagged claims. Her job is to confirm that closing the coverage gap does not open a security or regulatory gap.

Her bar has three parts. First, a SOC 2 report in hand, with the audit period current and the scoped criteria readable. Second, a specific set of data-handling controls beyond SOC 2 documented in the security addendum and provable on architecture review. Third, a documented map from the vendor's controls to the state regulatory frame the carrier files under. Each part fails independently. A vendor with a clean SOC 2 but no model-training-boundary clause fails. A vendor with strong controls but no NAIC Model #668 awareness fails.

Integration shape and security posture move together in this review. Priya looks at where the data sits before she looks at the architecture diagram, and the two conversations happen in the same meeting. See hidden integration costs for legacy claims AI for why the integration shape itself surfaces security questions a generic SaaS review will miss.

A SOC 2 Type II report attests that controls at a service organization operated effectively over a stated period - usually 6 to 12 months - against one or more of the five AICPA Trust Services Criteria. The five criteria, per the AICPA SOC 2 overview, are Security, Availability, Processing Integrity, Confidentiality, and Privacy. Only Security is mandatory in every SOC 2 audit. The other four are optional, scoped in at the service organization's election.

This is the single most misread fact in vendor-security procurement. A vendor can hold a current SOC 2 Type II certificate that scoped only Security. That certificate is real and the report is genuine, but it says nothing about how the vendor handles confidential data, how it protects privacy, or how it ensures processing integrity. Priya reads the scope page, not the cover.

Type I versus Type II is a scoping fact worth knowing. A SOC 2 Type I report attests that controls were designed appropriately at a single point in time. Type II attests that those controls operated effectively over the audit period. For an enterprise AI fraud investigation procurement, ask which type the report is and read it accordingly - the type tells you what the attestation covers, and the scope page tells you what it examined. Either way, what carries the review is a current report with readable scope and a documented audit cadence.

Most security reviews file the SOC 2 PDF and move straight to the questionnaire. Reading the report takes an hour and changes decisions. Five places to look before the vendor call:

• Exceptions and qualified opinions. The auditor's opinion section lists controls that failed testing during the period. An exception is not automatically disqualifying, but an exception against access control or change management at a vendor handling claim files needs a written remediation answer, not a verbal one.
• Complementary user entity controls (CUECs). Every SOC 2 report assumes the customer operates certain controls on its own side - provisioning users, revoking access on termination, configuring retention. If nobody at the carrier owns the CUEC list, the attestation has a hole in it that is the carrier's responsibility, not the vendor's.
• Carve-out vs inclusive subservice organizations. Most reports carve out subservice organizations - the cloud platform, the model-inference provider - which means their controls were named but never tested. A carve-out is standard practice; it also means the carrier needs those providers' own reports (covered below).
• Bridge letters. If the audit period ended more than three months ago, ask for a bridge letter attesting that controls have not materially changed since the period closed. A report whose period ended ten months ago, with no bridge letter, is stale evidence.
• The auditor itself. A SOC 2 examination can only be issued by a licensed CPA firm. Confirm the firm exists, is independent, and runs a real attestation practice - a two-minute check against the state board of accountancy that almost nobody performs.

Verification stopped being paranoia in 2026. After a supply-chain incident at LiteLLM, a widely deployed open-source LLM gateway, the SOC 2 Type II and ISO 27001 badges in its documentation came under public scrutiny, alongside whistleblower allegations that its compliance platform, Delve, had produced near-identical SOC 2 report artifacts across hundreds of companies - allegations Delve denies, and LiteLLM has since moved to recertify with independent auditors. A badge on a website is a claim, not evidence. Ask for the report itself under NDA, match the period dates against the badge, and read the signature page.

The disclosure standard cuts both ways, so here is ours: Hesper holds a SOC 2 Type I attestation and shares the report under NDA, with scope and audit dates, on the first security call. That is the plain answer Priya should demand from every vendor in the review. A vendor that says "we are SOC 2 compliant" without naming the type, the period, and the scoped criteria has answered nothing.

SOC 2 frames the question. The answer is in the specific control set. Seven controls survive the procurement conversation when nonpublic information flows from a Carrier CIO's environment into an AI investigation vendor: encryption at rest and in transit, tenant isolation, data residency, PII minimization, the model-training boundary, sub-processor disclosure (with breach-notification SLA), and retention and deletion. Each one connects to a specific clause in the state regulatory frame and to a specific question the carrier's GC will ask if a case ever reaches deposition.

The model-training-boundary clause is the single most contested line in the contract. Many AI vendors have default terms that allow customer data to be used for model improvement. That is unworkable for a P&C carrier because claim data is nonpublic information under NYDFS 500 and Model #668, and it may include protected health information under HIPAA. The procurement-ready posture is: customer claims data is not used for cross-customer training by default. If the vendor cannot answer this in writing, the review pauses.

For a broader vendor-evaluation rubric that includes commercial, integration, and operational questions alongside this security set, see our vendor-evaluation checklist for AI fraud investigation. This post is the security-specific subset.

A Carrier CIO is deploying inside a regulated frame. The NAIC adopted the Insurance Data Security Model Law (Model #668) in 2017, designed to align with NYDFS 23 NYCRR 500. Per the NAIC's August 2025 government affairs brief, 28 jurisdictions have enacted it. Both Model #668 and NYDFS 500 require insurance licensees to oversee third-party service providers handling nonpublic information, encrypt that information, and notify the regulator within 72 hours of a determined cybersecurity event. An AI fraud investigation vendor is a third-party service provider under both frames.

The third-party oversight requirement lives in 23 NYCRR 500.11. It mandates a written policy with four elements: identification and risk assessment of third-party providers, a due-diligence process for selecting them, minimum cybersecurity practices required of providers, and periodic reassessment. The vendor security addendum has to map cleanly to those four elements. The NYDFS Second Amendment, effective November 1, 2023, tightened MFA, encryption, and breach-notification expectations across the board.

Model #668 §4 requires every licensee to submit an annual written certification of compliance to the state insurance commissioner by February 15. The vendor's security posture and data-handling controls feed directly into that certification. If the vendor cannot produce evidence on a 30-day cycle - audit reports, sub-processor changes, breach-notification logs - the carrier's own filing weakens.

Model #668 fine print: exemptions, enforcement, and the preemption clock

Four pieces of fine print shape the review, and they live in the NAIC's own brief rather than in vendor marketing. First, a licensee certified compliant with HIPAA's information-security requirements is exempt from Model #668's Section 4 program requirements - but not from Section 5's duty to investigate cybersecurity events or Section 6's 72-hour notification to the commissioner, so "we are HIPAA compliant" does not shorten the breach chain. Second, licensees with fewer than ten employees get the same Section 4 carve-out. Third, the model law creates no private cause of action; enforcement runs through the state insurance commissioner under existing insurance-code penalty provisions, and state data-security enforcement actions against licensees have already produced six-figure penalties. Fourth, the US Treasury warned that if states failed to reach uniform adoption within five years, Congress should consider federal preemption - the pressure that keeps the adoption count climbing.

For the vendor review, the operative clause is §4F: the licensee must exercise due diligence in selecting third-party service providers and require them to implement appropriate security measures. After a cybersecurity event, the vendor-oversight file - the due-diligence record, the contract clauses, the reassessment cadence - is the first thing an examiner pulls. "We trust our vendor" is not examination-ready evidence.

The audit substrate matters as much as the policy. Hesper is built audit-trail-native: 15+ investigation phases run in parallel on every flagged claim and each phase logs sources, reasoning, and timestamps. That per-case, per-action evidence chain maps directly to California 10 CCR 2698.36's documented-decision requirement and to the documented investigation history a state DOI may pull on audit. For where in the stack this sits, see prevention vs detection vs investigation. Detection vendors emit a score; an investigation vendor emits a reconstructable evidence chain.

Workers compensation, auto bodily injury, life, and health claims routinely include medical records. The moment protected health information flows through an AI vendor's systems, the vendor is a Business Associate under the HIPAA Security Rule and a written Business Associate Agreement is required before the data flows. This is not a negotiation item. If the vendor will not sign a BAA, the deal stops there for any line that touches medical records.

The BAA obligates the vendor to implement the administrative, physical, and technical safeguards required under the Security Rule, to report breaches to the covered entity, and to require equivalent obligations of any sub-processor. The vendor's sub-processor list is a hard input here. A cloud provider, an OSINT data vendor, or a model-inference provider that touches PHI is a sub-business-associate and needs its own BAA chain.

GLBA sits underneath HIPAA as a broader federal floor on insurer data handling. The state frame - NAIC Model #668, NYDFS 500, California 10 CCR 2698.36 - layers on top. The vendor's data-handling controls need to satisfy all four simultaneously, which is why a generic SaaS security posture is not sufficient for a carrier deployment.

SOC 2 attests that controls operated. It is not an AI-governance framework, and an AI vendor security review in insurance increasingly asks for more than one artifact. Three frameworks cover ground SOC 2 does not:

• ISO/IEC 27001 certifies an information security management system against a fixed control catalog. Where SOC 2 attests to controls the vendor chose to scope, ISO 27001 certifies the management system itself. Global carriers and reinsurers often ask for it alongside SOC 2; the two overlap heavily, and a vendor holding either should be able to map to the other on request.
• ISO/IEC 42001, published December 2023, is the first certifiable AI management system standard. It covers what SOC 2 never touches: AI impact assessments, model lifecycle management, human-oversight provisions, and documentation of intended use - the questions a carrier's model-risk team asks that the security questionnaire does not.
• NIST AI RMF is the voluntary US framework (Govern, Map, Measure, Manage) whose vocabulary examiners increasingly borrow. The NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers, adopted December 2023, expects carriers to maintain a written AI program and to oversee third-party AI systems - which makes the vendor's willingness to feed that oversight program a procurement criterion in its own right.

None of these replace the Model #668 file. What a state examiner asks to see is documentation: the vendor's attestation reports, the carrier's due-diligence record, the contract clauses implementing minimum security practices, the reassessment cadence, and - for AI systems - evidence of how the carrier oversees the vendor's model behavior in production. This is where an investigation platform that logs every phase pays twice: the same per-case evidence chain that defends a fraud referral is the vendor-oversight evidence the exam asks for.

The sub-processor boundary: your vendor's SOC 2 does not cover its model provider

The least-read page of an AI vendor's SOC 2 report is the subservice-organization section, and it hides the question that matters most. In a carve-out report, the model-inference provider your claim narratives actually reach sits outside the audit boundary: the vendor's controls were tested, the LLM provider's were not. Three artifacts close the gap, and all three belong in the security addendum - the sub-processor's own current SOC 2 or ISO 27001 report, held by the vendor and available to the carrier on request; a BAA chain that extends to every sub-processor touching PHI, not just the vendor itself; and a 30-day advance notification for any sub-processor change, so the §4F oversight file never goes stale silently.

Ask the question in exactly this form: "Which subservice organizations are carved out of your SOC 2 report, and what evidence do you hold on each?" A vendor that has never been asked will pause. A vendor running a real third-party risk program will send a table.

Priya hands this list to the vendor for written response before the security-review meeting. The vendor that answers cleanly in writing is the vendor that survives the review.

1. Current SOC 2 report, issued within the last 12 months, with next audit period scheduled.
2. Trust Services Criteria scoped in: Security plus Confidentiality at minimum, Privacy if PHI flows, Processing Integrity if audit trail is part of the procurement value.
3. Published list of sub-processors with what each one processes and where, plus 30-day change-notification commitment.
4. Training-data policy in writing: customer claims data is not used for cross-customer model training by default, contract clause confirming.
5. Data-residency map: US-region pinning available, regional architecture diagram, no required egress to non-US regions for claim data or OSINT processing.
6. Tenant-isolation architecture: per-tenant key separation, no shared model fine-tunes across customers, written description.
7. Encryption specifications: AES-256 at rest, TLS 1.2+ in transit, customer-managed key option, key-rotation policy.
8. HIPAA BAA willingness in writing if any line of business carries PHI.
9. Breach-notification SLA: vendor notifies carrier within 24-48 hours of a confirmed cybersecurity event, in writing, with scope assessment and named-contact protocol.
10. Retention and deletion policy: configurable retention, contractual deletion-on-termination, written certification of deletion.
11. Evidence of NYDFS 23 NYCRR 500 or NAIC Model #668 awareness in the vendor's security program (mapping document, not just a marketing statement).
12. Per-case audit-trail architecture: how investigation actions are logged, retained, and produced on regulatory request.

The last item on the list is the one most generic AI vendors fumble. Hesper emits a per-case audit trail because the investigation architecture is built that way: 15+ phases run in parallel on every flagged claim and each phase logs its sources, reasoning, and timestamps. The audit trail is not a feature added on top of the product. It is the product.