Cyber underwriters expect a SaaS or tech company to bring two things to market: a program that pairs technology errors and omissions coverage with cyber liability — because a single outage or breach produces both your customers’ losses and your own — and security controls the company can actually document, starting with multi-factor authentication everywhere, tested and segregated backups, endpoint detection, and a written incident response plan.

A SaaS company’s insurance file doesn’t look like other businesses’. The product is software, the inventory is customer data, and the worst day triggers two claims at once — customers alleging the platform failed them, and the company absorbing its own breach costs in the same event. This article walks through why tech E&O and cyber have to be structured as one program rather than two purchases, where customer data exposure really sits in the contracts, what cyber underwriters now expect a tech company to prove before quoting, and what a SOC 2 report does — and doesn’t do — in front of an underwriter.

• Why do SaaS companies need tech E&O and cyber as one program?
• Where does customer data exposure actually sit for a SaaS company?
• What controls do cyber underwriters expect a tech company to prove?
• Does a SOC 2 report replace underwriting — or feed it?
• What deserves scrutiny in a SaaS cyber quote?
• How should a SaaS company prepare before going to market?

Why do SaaS companies need tech E&O and cyber as one program?

Start with what happens on the bad day. The platform goes down, or customer data leaks through it. The company’s own losses — forensics, notification, restoration, lost revenue — are a cyber claim. The customers’ losses — the workflows they couldn’t run, the data they entrusted to the platform — come back as claims that the product failed to perform, and those are not cyber claims at all.

Technology errors and omissions (tech E&O) is professional liability for a technology company — it responds when the product or service fails to perform as promised and customers claim financial harm, which a cyber policy alone does not cover. Buy cyber without tech E&O and the customer-facing half of the loss is bare. Buy them from different carriers on different forms, and the two policies can each point at the other while the claim sits in the seam.

That’s why the market that has been trained to receive a quote and buy the cheapest thing gets this class wrong. A fast commercial insurance quote prices two products; a properly built program structures cyber liability and tech E&O as one placement — ideally one carrier, one form, one set of definitions — so a single event can’t be split into two partial denials.

Where does customer data exposure actually sit for a SaaS company?

In the contracts — usually before anyone reads the policy.

A SaaS company holds data for others at scale. Every enterprise customer agreement, master services agreement, and data processing addendum makes promises about that data: security standards, breach notification timelines, indemnification, sometimes uncapped liability carve-outs for data breaches. When an incident hits, those contractual promises decide who owes what long before coverage does — and a policy with narrow contractual liability language can leave the company holding obligations it assumed in writing but never transferred.

This is the keep-versus-transfer question applied to a customer base: every indemnity clause a sales team accepts is risk the company is keeping until the insurance program is read against it. The same logic covers professional liability generally — the promises in the contract define the exposure, and the policy either matches them or it doesn’t.

What controls do cyber underwriters expect a tech company to prove?

There is a real underwriter behind every cyber quote, opening a file on the account and taking notes in it — and for a tech company, that file is mostly a controls review. The era of two-question cyber applications is over. What underwriters now commonly expect a SaaS company to demonstrate, in writing and sometimes in a call with the carrier’s security team:

Multi-factor authentication on email, remote access, and privileged accounts — not “mostly deployed,” deployed. Backups that are tested, segregated from production, and restorable on a known timeline. Endpoint detection and response on the fleet. A written incident response plan someone has actually rehearsed. Patching cadence and end-of-life software handling. Vendor and open-source dependency management. Privileged access management for the engineers who can touch production.

The point isn’t the checklist — it’s that answers to these questions now move terms, retentions, sublimits, and sometimes insurability itself. A company that can’t show MFA on privileged access may not see a quote at all; a company with a documented, rehearsed program gets access to markets and terms the incomplete file never sees. Completeness is what makes a submission stand out — a full file paints a picture that gives an account access to markets a thin file can’t reach, and a thin file in this class is nearly always quoted defensively or declined.

Does a SOC 2 report replace underwriting — or feed it?

SOC 2 is an independent audit report on a service company’s controls — security, availability, confidentiality — that enterprise customers routinely demand before trusting a vendor with their data. If a SaaS company sells to serious customers, it has already been underwritten repeatedly: security questionnaires, vendor reviews, audit requests. The carrier is doing the same diligence the customers did, for the same reason — it is deciding whether the company is a good investment.

So the report helps, and it is not a substitute. A clean SOC 2 Type II makes the underwriter’s file easier to say yes to: it corroborates the application’s claims, shortens the security call, and signals a company that runs the way its marketing says it does. But underwriters still ask their own questions, because a SOC 2 scope is defined by the company and an application is a warranty by it — misdescribing controls on an application is handing the carrier a question to raise at claim time. Treat the SOC 2 as evidence in the submission, not a hall pass around it.

What deserves scrutiny in a SaaS cyber quote?

Once quotes arrive, the number at the bottom is the least informative line on the page. What decides the outcome for a tech company: the retention — how much risk the company is keeping per event, and whether it’s sized to the balance sheet or to a guess. Sublimits on the coverages a SaaS loss actually uses, the same quiet mechanics of sublimits, exclusions, and conditions that decide most coverage disputes — and the specific traps already mapped in ransomware coverage gaps. Failure-to-perform and contractual liability exclusions read against the actual customer agreements. Whether business interruption terms fit a company whose revenue is uptime — including how the program treats an outage at the cloud provider the whole product runs on, a dependent business interruption question big enough to deserve its own article.

Every one of those is invisible on a premium comparison, and every one of them is exactly where coverage that looked fine on paper fails when it actually matters.

How should a SaaS company prepare before going to market?

Assemble the file an underwriter wants to read before any broker touches the market: the controls story with evidence (MFA scope, backup testing, EDR, the IR plan), the SOC 2 if it exists, the customer-contract posture on indemnity and data promises, revenue mix, and loss history. Then approach the market deliberately — in commercial insurance a carrier releases one quote to one agent, so broker selection and market strategy come first, not last.

The timing favors doing it now. As of mid-2026 the cyber market has softened substantially, and well-documented tech accounts are seeing broader coverage at the same or better cost than their expiring terms — the soft market is rewarding exactly the documentation discipline underwriters started demanding in the hard one. Des Moines and the surrounding corridor have built a real base of software, fintech, and insurtech companies inside one of the country’s most concentrated insurance towns; the carriers are local, and so is the expectation that a tech account shows up prepared.

This preparation is a core module of the Business Risk Diagnostic™, Avanti Group’s pre-quote due diligence: mapping the tech E&O/cyber seam against your actual customer contracts, laying your controls against what the market expects to see, and building the submission file before anyone asks for a quote. Most of the market quotes tech accounts fast and lets the underwriter find the holes; the Diagnostic finds them first, then takes your cyber program and the rest of your commercial program to market as a complete file.

Frequently Asked Questions

What is the difference between tech E&O and cyber insurance?

Tech E&O is professional liability for a technology company — it responds when customers claim the product or service failed to perform and caused them financial harm. Cyber liability covers the company’s own breach and outage costs (forensics, notification, restoration, lost income) and its liability for compromised data. A SaaS incident routinely triggers both, which is why they should be structured as one program rather than bought separately.

Do SaaS companies need both tech E&O and cyber coverage?

Almost always. Cyber alone leaves customer claims of product failure uncovered; tech E&O alone leaves the company’s own breach costs uncovered. One outage produces both kinds of loss at once, and placing the two coverages on one form with one carrier prevents a single event from being split into two partial denials.

What security controls do cyber underwriters require?

The consistent core: multi-factor authentication on email, remote access, and privileged accounts; tested backups segregated from production; endpoint detection and response; and a written, rehearsed incident response plan. Underwriters also commonly review patching, vendor management, and privileged access. Weak or undocumented controls now affect terms, retentions, and insurability — not just price.

Does a SOC 2 report lower cyber insurance premiums?

It helps the file rather than guaranteeing a number. A clean SOC 2 Type II corroborates the application, shortens the carrier’s security review, and supports access to better markets and terms. But carriers still underwrite independently — the report’s scope is set by the company, while the application is a warranty to the carrier, and the application is what matters at claim time.

Does cyber insurance cover a SaaS platform outage?

The company’s own lost income can be covered under cyber business interruption, subject to a waiting period and how the policy measures the loss. Customers’ losses from the outage fall to tech E&O, not cyber. And if the outage originates at the cloud provider the platform runs on, coverage depends on dependent (contingent) business interruption terms — a distinct and often sublimited coverage worth reviewing on its own.

Related reading

Other articles in the Commercial Foundations series:

• Dependent Business Interruption: The Cyber Gap Most Policies Miss — Standard cyber business interruption only responds when the failure happens on your own network — dependent (contingent) business interruption extends that income protection to outages and security failures at the third parties the business actually runs on: the cloud host, the payment processor, the critical software vendor. The coverage turns on which vendors sit inside the policy’s definition, whether the trigger is a security failure (an actual attack on the vendor) or the broader system failure (any unplanned outage, including the vendor’s own error — how most real outages happen), and the sublimits and hours-long waiting periods that quietly shrink the grant; the property policy’s dependent coverage requires physical damage and never reaches a cloud outage, so the two grants have to be read side by side. Seventh article in the Cyber Liability cluster — the cluster’s dedicated vendor-dependence piece.