Does an insurance vendor need SOC 2, and what does it take?
A carrier, managing general agent or insurtech customer has sent a security questionnaire or a contract clause asking for a SOC 2 report. Before you answer, separate the request from the law behind it. SOC 2 is not itself an NAIC requirement. The NAIC Insurance Data Security Model Law (#668) requires the licensee to exercise due diligence in selecting third-party service providers and to require them to implement appropriate safeguards (Section 4F). A SOC 2 report is one common way a licensee can evidence that oversight, but the statute does not name it. Your customer may also be bound by state adoptions of the model law, its own board policies or a regulator's third-party guidance, so ask which of these is driving the clause. The demand may be a SOC 2 Type 1, a Type 2, a SOC 2+ with additional criteria, or simply a completed questionnaire, and each answer has a different cost and timeline.
The organization you serve owns its controls. An implementation partner can prepare systems, configure self-hosted open-source platforms and assemble evidence for the examination, but that partner does not issue the report. Only an independent CPA firm can examine your controls and issue a SOC 2 report under the AICPA attestation standards. Whether you need a SOC 2 at all, and what it must cover, depends on the customer. Ask the customer which Trust Services Criteria they expect. Security is covered by the common criteria CC1 to CC9, which apply to every SOC 2, while availability, confidentiality, processing integrity and privacy are added only when they are in scope. Insurance data often brings confidentiality and privacy into scope, which changes the control set and the evidence you must produce.
Before you commit, put three questions to the customer in writing: which report type and period they will accept, whether they will accept a bridge letter or a report from a prior period, and which criteria their third-party oversight file requires. Then check your own readiness against the controls they are likely to test, including vendor risk management under CC9.2 and the protections the model law lists in Section 4D. Confirm the scope and fees with the CPA firm and any implementation partner in a written engagement letter before work starts.
Which security measures insurers expect vendors to show
The NAIC model law lists security measures that a licensee implements where appropriate, and insurers pass those expectations down to their vendors through due diligence. Each card below pairs one measure with the SOC 2 criteria that carry it and the evidence an assessor would sample.
Encryption of nonpublic information
Section 4D points to encryption of nonpublic information sent over external networks and stored on portable devices. In SOC 2 this sits mainly under CC6.7, which covers restricting transmission, using encryption or secure channels, protecting removable media and protecting endpoint devices. Check how data leaves your environment, which laptops and backup media hold insurer data, and whether encryption is enforced by configuration rather than by staff habit. An assessor typically samples TLS settings on external endpoints, disk encryption status on a set of endpoints, and the key management records behind them.
Multi-factor authentication where appropriate
Section 4D lists multi-factor authentication as an effective control where appropriate. SOC 2 carries this under CC6.6, which covers restricting access, protecting credentials and requiring additional authentication. Insurers will expect MFA on administrator consoles, production access and any portal where their staff or agents see nonpublic information. Confirm which accounts are excluded and why. Assessors usually sample identity provider policy exports, MFA enrollment lists for privileged users and records of exceptions approved by management.
Boundary protection for insurer data
Points of focus under CC6.6 also cover implementing boundary protection systems. For an insurtech, this means firewalls, network segmentation and controlled ingress around the systems that hold policy, claims or underwriting data. Insurers ask whether a compromise of a marketing or reporting system could reach the claims database. Assessors commonly sample firewall rule reviews, network diagrams showing segmentation and records of rule changes approved through the change process.
Secure development practices
Section 4D names secure development practices. In SOC 2 the evidence lands mainly under CC8, which covers how changes to software and infrastructure are authorized, built, tested, approved and deployed. Insurers want to see code review before merge, automated security scanning in the build pipeline and separation between the people who write changes and those who approve them. Assessors usually sample pull requests with reviewer approvals, pipeline logs showing scan results and deployment approvals for a set of releases.
Audit trails and security monitoring
Section 4D lists audit trails as a measure to implement where appropriate. SOC 2 covers this under CC7, which addresses monitoring for anomalies, evaluating security events and responding to them. Insurers expect logs that show who accessed nonpublic information, when administrators changed configurations and how alerts were handled. Confirm retention periods with the insurer, since they often set them in contract. Assessors typically sample log extracts for privileged actions, alert tickets and evidence that someone reviewed them.
Mapping insurer expectations to SOC 2 criteria
This table pairs each insurer-side duty from the NAIC model law with the SOC 2 common criteria an assessor would likely test for it. Use it as a working aid to plan evidence, not as a substitute for the insurer's own questionnaire, which should be checked line by line. Not every point of focus under a criterion has to be addressed, so confirm scope with your CPA firm.
| Insurer expectation | Relevant SOC 2 criteria | Evidence an assessor usually expects |
|---|---|---|
| Oversight of third-party service providers (NAIC Section 4F) | CC9.2, managing risks from vendors and business partners | Vendor inventory, risk-tiered due diligence records, contract security terms, and periodic vendor review |
| Access and credentials for nonpublic information | CC6.1 and CC6.6, logical access and credential protection | Access request and approval records, quarterly or periodic access reviews, MFA configuration, and joiner and leaver records |
| Encryption of nonpublic information in transit and at rest (NAIC Section 4D) | CC6.7, restricting transmission and protecting data in transit | TLS configuration, encryption settings for storage and backups, and removable media or endpoint controls |
| Audit trails for access to and changes in sensitive data | CC7.2, monitoring of system components and security events | Log sources, retention settings, alert rules, and samples of reviewed security events |
| Secure development practices (NAIC Section 4D) | CC8.1, change management for software and infrastructure | Ticketed changes, peer review records, test results before release, and approval evidence |
| Written incident response plan (NAIC Sections 4D and 4H) | CC7.3 to CC7.5 and CC9.1, incident handling and business disruption | Incident response plan, tabletop exercise records, incident tickets, and recovery test results |
| Risk assessment covering the program and third-party use | CC3.1 to CC3.4, objectives and risk identification | Annual risk assessment, risk register with owners, and documented updates after significant changes |
When availability, confidentiality or privacy criteria apply
The security category is always in scope. The common criteria CC1 to CC9 apply to every SOC 2 examination, whatever else the report covers. The other four categories, availability (A1), confidentiality (C1), processing integrity (PI1) and privacy (P1 to P8), are added only when the organization or its customers decide to include them in the examination. For an insurtech or an insurance industry vendor, the decision is rarely about whether the security criteria apply. It is about which additional categories the insurer's vendor questionnaire, contract or oversight program expects to see. For reference, the 2017 Trust Services Criteria contain 33 common criteria, 3 availability criteria, 2 confidentiality criteria, 5 processing integrity criteria and 18 privacy criteria, so a scope that adds a category adds those criteria to the examination and to the system description.
Confidentiality and privacy are the categories insurers ask about most often, because policy and claims platforms hold nonpublic personal information about policyholders, claimants and sometimes beneficiaries. Before you accept a scope, write down where that information is stored, which of your systems process it, which subservice organizations touch it, and how long each copy is kept. The confidentiality criteria then focus on identifying and protecting that information and on disposing of it when it is no longer needed, and the privacy criteria address notice, collection, use, retention, disposal and access. Illustrative example: a claims intake service that stores scanned medical attachments for an insurer may need the confidentiality criteria in scope even if the rest of the platform only needs security. Confirm the exact data flows with the insurer's third-party risk team rather than assuming the category that matches the word privacy.
Type 1 or Type 2, and general use or restricted report
A SOC 2 Type 1 report describes the vendor's system and states whether the controls were suitably designed as of a specific date. It does not test whether those controls worked over time. For a vendor newly entering insurance sales, a Type 1 can be a practical first step, because it shows the controls exist and are laid out properly while the vendor builds a track record. Many carriers accept it as an early assurance point while a longer examination is under way, but whether they do is a decision for each customer's third-party risk team.
- Point-in-time scope: The report covers the system and control design as of one date, so it reflects the environment on that day only.
- Design, not operation: An auditor confirms the controls are designed to meet the criteria, not that staff performed them consistently.
- Typical use: Vendors use it to enter a sales process, then follow with a Type 2 once operating history exists.
- Limits for carriers: A carrier that relies on ongoing controls for nonpublic information may still need operating evidence.
- Planning: Ask the customer whether a Type 1 meets its vendor oversight file before you commit to a date.
Check with the customer's vendor management team whether a Type 1 satisfies its due diligence, and confirm the report date and system description your auditor will use.
A SOC 2 Type 2 report adds an auditor's opinion on whether the controls operated effectively over a defined observation period. This is the report most carriers have in mind when they ask whether a vendor's security controls actually run. Under the third-party oversight duties in the NAIC Insurance Data Security Model Law, a licensee must exercise due diligence in selecting a provider and require it to maintain appropriate measures, and a Type 2 is typically the stronger evidence of that ongoing operation.
- Observation period: The auditor tests controls across a period rather than on one date, and the report states the period covered.
- Operating evidence: Samples of access reviews, change approvals, monitoring alerts and incident handling are tested across the period.
- Exceptions: Any control failures found in testing are disclosed in the report, so reviewers read the exceptions section closely.
- Gap risk: Periods that are not covered by the report leave a gap that customers may ask you to bridge.
- Period length: Do not assume a duration. Confirm the required observation period with the customer and your auditor before the examination starts.
Ask the carrier whether it expects a Type 2 for the services in scope, and confirm the observation period and any bridge letter requirements in writing.
A SOC 2 report is generally restricted in use. Under the AICPA's framework, the report is intended for management, the customers that have accepted it or who are subject to the controls, and the parties that need to understand the system. Insurers, insurtechs and their vendors should expect the full report to move only under a non-disclosure agreement or a similar arrangement, and recipients should check that their use fits the restriction before sharing it further.
- Who may receive it: Typically current customers, prospective customers under NDA and parties with a legitimate oversight need, as described in the report itself.
- Full detail: The restricted report includes the system description, the criteria, tests performed and any exceptions.
- Onward sharing: Sharing with regulators, reinsurers or affiliates may need separate approval, so confirm that path early.
- Contract terms: Put report access, delivery and confidentiality terms into the agreement with the carrier.
- Review: Ask your auditor how the restriction language should read in your report and in your sales materials.
Confirm with your auditor and legal counsel exactly who may receive the restricted report, and agree that wording with each carrier before the first request.
A SOC 3 report covers the same trust services categories as a SOC 2 but in less detail. It is a general use report, which means it can be freely distributed, including on a public website or in a sales pack. That makes it useful early in an insurance sales cycle, when a prospect wants a shareable signal of security practice before the NDA stage. It does not replace the SOC 2 for a carrier that needs control-level detail for its vendor file.
- Broad distribution: Because it is general use, it can be posted publicly or attached to proposals without an NDA.
- Less detail: It omits the detailed description of controls, tests and exceptions that appear in a SOC 2.
- Complement, not substitute: Carriers usually still request the SOC 2 itself for due diligence.
- Same categories: The categories examined match the SOC 2, so the scope discussion carries over.
- Marketing use: Confirm the auditor's rules on use of the SOC logo and how the report is described on your site.
Ask prospects which report they need for their file, and confirm with your CPA firm which version to publish and how it should be labeled.
How a SOC 2 for an insurance vendor moves from scoping to report
The sequence turns a vague customer request into a system description, a tested set of controls and an independent report that an insurer's third-party review can rely on. Each phase produces a named artifact, and the examination closes only after the auditor has tested evidence over the period.
Define scope and the system description
The vendor decides which product, environments, data flows and support functions fall inside the examination, and which Trust Services Criteria categories apply. For an insurance vendor, security is always included, while confidentiality, availability, processing integrity or privacy are added only when the insurer's contract and data use call for them. Management drafts the system description against the AICPA 2018 description criteria, covering infrastructure, software, people, procedures and data, plus the subservice organizations, such as cloud hosting providers, that the system relies on. The output is a scope statement and a draft system description that the auditor reviews before fieldwork is planned. Ask the auditor to confirm the scope in writing through the engagement letter.
Run a gap assessment against the criteria
The team maps existing policies, technical settings and records to the common criteria CC1 to CC9 and to any added categories in scope. Work through the insurer's expectations as well, including encryption of nonpublic information, multi-factor authentication, secure development and audit trails, and check how each lines up with the criteria, such as CC6.6 for access and boundary protection, CC6.7 for transmission and removable media, and CC9.2 for vendor risk. The output is a gap register that lists each criterion, the existing control, the missing or weak element, an owner and a target action. Points of focus are used to test design, not as a checklist that every item must satisfy.
Remediate controls and build the evidence trail
Owners close the gaps in the gap register. This phase changes configurations, writes or revises policies, sets up logging and access reviews, documents vendor due diligence and tests incident response and recovery procedures. Evidence must be generated as a normal part of operations, such as access review records, change tickets, log exports and training completions, because a Type 2 examination tests whether controls worked across the period. The output is a remediated control set, a control matrix linking each control to its criteria and evidence source, and a dated record showing when each change went live. Implementation partners can prepare systems and evidence in this phase, but the organization owns the controls.
Prepare management's assertion and description
Management finalizes the system description and writes its assertion that the description is fairly presented and that the controls are suitably designed, and for a Type 2 report, operating effectively over the period. Leadership reviews these statements and confirms that the description discloses the subservice organizations and the complementary user entity controls that the insurer must perform on its side. The output is a signed management assertion and a final system description ready for the auditor's review. This is also where the organization confirms the facts it will later repeat in the written representation letter.
Complete the examination under AT-C section 205
The independent CPA firm performs the examination under AT-C section 205 of the AICPA attestation standards. The auditor tests the design of controls for a Type 1 report, or design and operating effectiveness over the observation period for a Type 2 report, using inquiry, observation, inspection of records and sampling. Before the report is issued, management provides written representations confirming the completeness of information given to the auditor and the accuracy of its assertions, and the auditor may ask for more evidence wherever exceptions are found. The output is a set of documented test results, a list of any exceptions and management's responses to them. Ask the firm to confirm in writing the observation period and the evidence requests it expects.
Receive the issued report and share it under controls
The CPA firm issues the SOC 2 report, which contains the auditor's opinion, the system description, the criteria, the tests performed and the results, including any exceptions. The vendor decides who receives the full report and under what terms, since use of a SOC 2 report is generally restricted to the parties named in it, and may issue a SOC 3 general use report for public distribution. The output is the signed report and a sharing plan that routes it to insurer security reviews under a nondisclosure agreement. Confirm with the insurer which report type and scope its third-party review needs before the report is shared.
What insurance vendors must have in place before the examination
An insurer or insurtech will ask for these items before it accepts a SOC 2 report as evidence of your controls. Each one maps to a duty in the NAIC model law or to a SOC 2 criterion, and each one is a record you must be able to show an auditor across the whole examination period.
Written information security policy
A board-approved or management-approved policy that sets security objectives, names the owner of each control and states how the policy is reviewed. Section 4D of the NAIC model law expects a program designed around identified risks, and CC1 and CC2 expect the people running controls to know what they are responsible for. Check the policy date, the approval record and whether the policy covers the insurer data you hold. The organization owns this document and its decisions, not the implementation partner.
Incident response plan with insurer timelines
A written plan under Sections 4D and 4H of the NAIC model law, with roles, escalation steps and communication templates. Ask each insurer client which notification window and content it expects, then confirm the plan can meet it, since the contract may be stricter than the model law. Check for a tabletop exercise record and for incident tickets showing the plan was followed. This is the main evidence behind CC7 incident response.
Access review records
Dated reviews in which a named manager confirms that each account on production systems, insurer data stores and admin consoles is still needed and has the right role. Pair the review with joiner, mover and leaver tickets so the auditor can trace removals. CC6.1 through CC6.3 test this directly, and the auditor will sample reviews across the period. Check that reviews cover service accounts and contractors, not only employees.
MFA and encryption evidence
Screenshots, configuration exports or identity provider reports showing MFA enforced for administrators, remote access and any path to nonpublic information, plus encryption settings for data in transit and at rest. Section 4D lists encryption and multi-factor authentication as measures to consider where appropriate, and CC6.6 and CC6.7 cover their points of focus. Confirm that the evidence is taken from the live environment, with the date, and not from policy wording alone.
Secure development and change records
Samples showing that code and infrastructure changes were requested, reviewed, tested and approved before deployment, with separation between the person who writes a change and the person who approves it. Section 4D names secure development practices, and CC8 tests change management across the period. Check that the pipeline logs, pull request approvals and deployment records can be matched to each other for the sampled changes.
Vendor records for your own subservice providers
Due diligence files for every cloud host, data processor or other provider that stores or processes insurer data on your behalf, including their SOC reports, contract security terms and periodic reviews. The NAIC model law requires due diligence in selecting third-party service providers, and CC9.2 requires you to assess and manage vendor risk. Record which subservice organization controls you rely on and how you monitor them, since the examination will ask for this.
System description naming insurer data flows
A system description that shows where insurer nonpublic information enters, moves through, is stored in and leaves your platform, including every integration with the insurer, broker or data partner. Management prepares this description against the AICPA description criteria, and the auditor evaluates it for accuracy. Confirm that each named flow matches a control in your control matrix and that the diagram is updated when integrations change.
Who does what: the insurer, the vendor, the partner and the CPA firm
The insurer or licensee is the party with the regulatory duty. Under the NAIC Insurance Data Security Model Law (#668), a licensee must exercise due diligence when selecting a third-party service provider and must require that provider to implement appropriate administrative, technical and physical measures to protect the information systems and nonpublic information it can access or holds. The insurer does not hand that duty to the vendor. It has to evaluate the vendor's controls and keep records of that evaluation.
- Due diligence file: Collect the vendor's SOC 2 report, its bridge letter where the report period has ended, and answers to a security questionnaire before signing.
- Contract terms: Set notice of security incidents, audit or assessment rights, data return and destruction, and subcontractor controls in the agreement.
- Risk tiering: Decide how much scrutiny a vendor gets based on the nonpublic information it touches.
- Ongoing oversight: Review each new report, exceptions and changes in scope, not only the first one.
- Written program: Record third-party risk within the licensee's information security program and incident response plan.
Before signing, confirm that the report covers the systems that will hold your data and that its period overlaps your contract term.
The vendor is the service organization that operates the system under examination. It owns its controls, writes the system description and is accountable for whether the controls operate as described. Management's assertion and its description of the system are the vendor's documents, not the auditor's. A SOC 2 is an assertion-based examination, so the vendor must give the CPA firm written representations.
- Controls ownership: Each control in the matrix has a named owner who performs it and keeps the records.
- System description: Describe the infrastructure, software, people, procedures and data, and state which subservice organizations are carved out.
- Policies and evidence: Write the policies, run access reviews, keep joiner and leaver records and retain change tickets.
- Vendor management: Assess the cloud provider, data processors and other subservice organizations that the insurer's data reaches.
- Insurer questions: Answer the security questionnaire accurately, since the insurer's due diligence depends on it.
Spend time on the system description early. Insurers read it closely, and a mismatch between it and the actual deployment is a common source of questions.
An implementation partner such as DeployOpen works for the vendor on the systems and evidence side of the program. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a SOC 2 readiness effort, that can include hardening the platform, configuring logging and monitoring, and setting up evidence collection. DeployOpen does not own the controls, does not write the vendor's management assertion and does not issue reports or attestations.
- Hardening and configuration: Prepare systems to support the controls the vendor has chosen, such as access restrictions, encryption and secure build pipelines.
- Logging and evidence: Set up audit trails and export records that show operation over time for the auditor.
- Documentation: Prepare runbooks and configuration records that match the system description.
- Fixed scope: Agree deliverables, scope and timelines in writing before work starts. Ongoing support is available as a retainer.
- No guarantee: Hiring a partner does not guarantee a clean report, a particular opinion or a passing examination.
Ask the partner which evidence it will produce, who will own each record afterward and what happens to the systems when the engagement ends.
The CPA firm is the independent service auditor. It performs the examination under the AICPA attestation standards, tests the controls and issues the SOC 2 report with its opinion. Only the CPA firm can do this. The firm must be independent of the vendor, which means it cannot design or implement the controls it later tests, and it will set its own scope, testing procedures and sampling.
- Engagement letter: Agree the scope, the categories included, the report type and the period before fieldwork begins.
- Type 1 or Type 2: A Type 1 report covers the design of controls at a date. A Type 2 report adds an opinion on operating effectiveness over a period.
- Fieldwork: Request evidence, test samples and document exceptions, which the report then discloses.
- Report distribution: Vendors generally share a SOC 2 under an NDA, while a SOC 3 is a general use report.
- Independence: Ask the firm how it handles situations where it also consults for the same vendor.
Before engaging a firm, ask about its peer review status, its experience with insurance or regulated clients and the timeline it expects for fieldwork.
Where insurance vendor SOC 2 projects stall
Insurance vendor SOC 2 projects rarely stall on the audit itself. They stall on assumptions made before fieldwork: what the report covers, where insurer data actually flows, what evidence exists for key controls, and whether the incident plan matches the insurer's notice obligations. Each card below names one of these delays and what to check early.
Assuming a SOC 2 answers every questionnaire
A SOC 2 report describes controls against the Trust Services Criteria for the system in scope. It does not answer questions about nonpublic information handling, insurer-specific audit rights or regulator-driven terms. Map each questionnaire item to a criterion, a policy or a contract clause before promising that the report covers it. Items with no match need a written answer or a separate control, and the vendor should say so plainly.
Unclear customer data flows
Insurers and insurtechs often send policy, claims and health-related data through APIs, file transfers, analytics tools and support systems. If the data flow map omits any of these, the system description will be incomplete and the auditor will test the wrong boundary. Build the map from production configuration and integration logs, then confirm every location where nonpublic information is stored, processed or transmitted.
Missing evidence for MFA and audit trails
Insurer questionnaires commonly ask whether multi-factor authentication covers remote access, administrators and vendor accounts. Auditors will test whether the control operates across the in-scope systems, which means the vendor needs exported configuration, sign-in logs and sampled access records for the full period. Confirm that logs are retained, protected from alteration and reviewed, since audit trail gaps are a frequent cause of exceptions.
Encryption without documented key ownership
The NAIC model law lists encryption of nonpublic information sent over external networks or stored on portable devices as a measure a licensee considers. Vendors often encrypt in transit and at rest but cannot show who manages keys, how rotation happens or whether backups and exports are covered. Document the key hierarchy, the systems that hold keys and the evidence (configuration exports, key policy records) that shows the controls operate.
Incident plans that ignore insurer timelines
A generic incident response plan may not reflect the notice obligations in an insurer's contract or the state rules that apply to the licensee. The NAIC model law requires a written incident response plan, and the vendor's plan must support the licensee's own response. Write notification steps, named contacts and the information insurers need into the plan, then run a tabletop exercise so the timeline is tested before a real event.
Vendor oversight that stops at the vendor
Insurers must exercise due diligence in selecting third-party service providers and require them to protect information systems. Insurtechs that rely on cloud hosts, claims platforms or data enrichment vendors need their own third-party register, risk reviews and evidence of those vendors' reports. Under CC9.2, the criterion on vendor and business partner risk, the auditor will ask how these relationships are assessed and monitored, so collect the reports and review records before fieldwork begins.
Questions insurance vendors ask about SOC 2
Does the NAIC model law require SOC 2?
No. The NAIC Insurance Data Security Model Law (#668) does not name SOC 2 or any other specific report. It requires the licensee to exercise due diligence when selecting a third-party service provider and to require that provider to implement appropriate administrative, technical and physical measures to protect the information it can access or holds. A SOC 2 is one way a vendor can give an insurer evidence for that oversight, but the insurer decides what evidence it accepts. Ask each insurer customer which documents its third-party risk process requires before you assume a report will close the question.
Will a SOC 2 report alone satisfy an insurer?
Usually not on its own. A SOC 2 shows that an independent CPA examined the controls described in your system description and tested them against the Trust Services Criteria for the scope you chose. It does not prove that every security measure an insurer must consider is in place, and it does not cover the contract terms, incident notification commitments or data handling that the insurer's oversight process may ask about. Expect insurers to send questionnaires, ask for the report's exceptions, and request evidence for items outside the report's scope, such as encryption of data in transit and at rest, multi-factor authentication for administrative access, and audit trails.
Should a carrier's vendor get a Type 1 or a Type 2 report?
Most insurers reviewing a vendor will want a Type 2 report, because a Type 1 covers the system description and the suitability of control design as of a single date, while a Type 2 adds an opinion on operating effectiveness over a period. A Type 1 can be a sensible first step for a new vendor that has not yet run controls long enough for a Type 2 observation window. Confirm with each customer whether a Type 1 is acceptable, and for how long, because that answer is a commercial and risk decision the insurer makes, not a rule in the model law.
How does the NAIC model law apply state by state?
The NAIC model law is a model. Each state decides whether to adopt it, in what form, and on what timetable, so the obligations that bind an insurer depend on the state where it is licensed. Vendors should not assume uniform adoption. Ask each customer which state insurance department's data security rules apply to it, and whether it is subject to any additional regulator expectations for third-party oversight. Your contracts should reflect the obligations your customers actually carry, which is why this question belongs with the insurer's compliance team and counsel.
How much effort does the vendor's own team need to provide?
The effort falls mainly on your engineering, security and operations staff, with finance, HR and legal involved in policies, vendor records and contracts. Your team writes or updates the system description, maps controls to the criteria, collects evidence such as access reviews, change tickets, backup restore tests and training records, and answers the auditor's requests during fieldwork. The effort is larger in the first examination and recurs for each period you report on. Ask any consultant or auditor to state in the written quote which artifacts they expect your team to produce, how many people it will take on your side, and how many review cycles are included.
Can a vendor run the SOC 2 in-house without outside help?
Yes, a vendor can run a SOC 2 with its own staff if it has the time, the skills to design controls against the Trust Services Criteria, and someone who can keep evidence consistent across the observation period. Many teams still bring in outside help to prepare systems, write control descriptions, and organize evidence, while the CPA firm performs the examination. An implementation partner such as DeployOpen can prepare self-hosted platforms and their evidence within the client's own infrastructure, but it does not issue reports. Only an independent CPA firm can examine and report on the controls, so the decision is about who does the preparation work, not who signs the opinion.
How should an insurtech choose a CPA firm for its SOC 2?
Choose a licensed CPA firm that performs SOC 2 examinations and has experience with service organizations of your size and architecture. Ask whether the firm has examined vendors serving insurers, how it samples evidence, how it handles exceptions, and whether your insurer customers already accept its reports. Request a written engagement letter that states the scope, the categories included, the report type, the observation period, the fee basis and the timetable, and confirm what you will be asked to provide. Also ask the firm whether it can prepare you as well as examine you, because independence rules may limit that combination.
What should a quote for insurance-focused SOC 2 readiness include?
A useful quote states the scope in writing: which systems, locations and vendors are covered, which Trust Services Criteria categories apply, and which report type is intended. It should list deliverables such as the control matrix, policy set, evidence collection method and remediation plan, and say which items the client must provide. Ask for the assumptions behind the effort estimate, what is one-time work such as system hardening and documentation, what recurs such as access reviews and penetration testing, and what changes the price, such as adding categories, new products or an additional observation period. DeployOpen issues quotes only from a written scope, and the auditor's fees are quoted separately by the CPA firm.
How DeployOpen prepares an insurance vendor's systems and evidence
DeployOpen is a Chainscore Labs company that plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, whether that is the client's cloud accounts, data centers or air-gapped networks. For an insurance vendor preparing for SOC 2, that means the platforms that hold or process policyholder and claims data, such as the ticketing, logging, identity, backup and deployment tooling that produce control evidence, are built in the vendor's own environment and configured to the controls the vendor has chosen to describe. The vendor keeps ownership of its controls, its policies and its system description. DeployOpen's role is to prepare the systems and the evidence trail the examination will sample.
Each engagement is fixed-scope. Before work starts, the parties agree in writing which platforms, control areas, environments and deliverables are included, along with the timeline and the handover items. Typical handover items include configuration baselines, access and change records, backup and restore test records, and documentation that maps each platform to the criteria it supports. Because the scope is written, the vendor can compare it directly against the control matrix it gives its CPA firm and ask what is excluded. Ask whether recurring work such as access reviews, upgrades and continuous testing is covered by a separate retainer, since those activities keep running after the first handover.
DeployOpen does not issue audit reports, attestations or certifications. Only an independent CPA firm can perform the SOC 2 examination and issue an opinion, and the insurer's own third-party risk team decides what it accepts from that report. Vendors should confirm early which CPA firm will examine the system, share the proposed scope with that firm, and agree which evidence it expects in the format it uses. A useful first step is to ask the auditor what it will sample in the observation period and to confirm that the DeployOpen deliverables match those requests.
