《独立开发者的商业指南·合同、应收与风险》6.1 E&O、网络安全险与雇主责任

以下情境为教学假设，人物与数字不代表经核实的真实案例。

保险在合同里通常只出现一行：供应商应维持不低于某个金额的责任保险。真正的问题不是「买不买」，而是三个险种各自覆盖哪类事故、保额相对收入是什么量级、保费换回来的覆盖倍数是否值得。对一人公司，保险不是合规装饰，而是把责任上限之后的尾部损失切出一块交给第三方。

Nord 的 E&O 保额是 $500,000，年收入 $154,320，覆盖倍数是 3.24 倍；LedgerLite 的网络安全险保额是 $1,000,000，年收入 $240,240，覆盖倍数是 4.16 倍。两个数字看起来都「够大」，但它们覆盖的是完全不同的事故：前者保咨询交付的错误与遗漏，后者保客户数据的泄露与响应。把两者放在一张表上，先看保额倍数，再看保费占比，才能判断保险到底改变了哪一段风险。

这一节只做三件事：区分三类险的保障对象、把保额换算成年收入的倍数、用保费算出每美元买到的保额。它不推荐具体产品，也不判断保单条款是否足够；保费与免赔都是教学假设，真实报价要以保单为准。

三类险各保什么

专业责任险（professional liability，常写成 E&O，errors and omissions）保的是「你提供的专业服务出了错」。对 Nord，这意味着咨询建议、交付物、项目管理和承诺的结果。客户因为你的错误建议多付了钱、错过了期限、被第三方追责，可能向 Nord 索赔；E&O 就是为这类第三方索赔设计的。它通常也覆盖抗辩费用，但抗辩费用是在总限额内还是单独限额，要看保单。

网络安全险（cyber liability）保的是「数据与系统出事之后的钱」。对 LedgerLite，这包括客户财务数据的泄露、勒索软件导致的停机、取证与通知成本、监管问询的抗辩，以及因违反 DPA 产生的第三方索赔。它和 E&O 的边界经常重叠：一次数据泄露既可能触发网络安全险，也可能因为「服务未达到专业标准」触发 E&O；两张保单同时存在时，通常由更具体的那张先赔，或者按各自条款分摊。

雇主责任险（employers’ liability）保的是「雇佣关系带来的索赔」。Nord 目前是两名合伙人加外包，没有正式员工；一旦招聘第三人，年成本 $55,000，雇佣关系就出现了，工伤、职业病的补偿，以及雇佣相关的争议，才进入保险范围。它和另外两类险的区别是：前两类保「对客户的损害」，这一类保「对劳动者的损害」。

这张表只能当作阅读保单前的索引，不能当保单本身。三类险的条款都会写覆盖和除外两套清单；同一类事故在不同保单里可能落在不同位置。判断一张保单保不保，最终要看它的除外责任、分项限额和追溯日，而不是看险种名字。

对独立开发者，最常见的错误是把「有保险」理解成「三类都保」。实际更常见的是只买了一张 E&O，却以为数据泄露也在里面；或者只买了一张网络安全险，却拿它去应对交付错误。险种名字不是覆盖范围，保单里的定义才是。

三类险的保费结构也不一样。E&O 通常按收入、服务类型和历史索赔定价；网络安全险按数据量、行业、安全措施和收入定价；雇主责任险按工资总额、岗位风险和员工人数定价。这意味着同一家公司在不同年份、不同业务结构下，三张保单的价格会以不同速度变化。Nord 从纯咨询转向咨询加产品，E&O 的定价基础会从「咨询小时」变成「咨询小时加订阅收入」；LedgerLite 从 260 家客户增长到 500 家，网络安全险的定价基础会从收入转向数据量。保险预算不是一次性数字，它跟着业务结构走。

这张表说明，保险不是「买一次，管三年」。业务结构变化时，保单的定价基础和承保范围都要重新核对；不核对，可能出现「保费按旧业务收、事故按新业务发生」的错配。

保额不是绝对值，是年收入的倍数

$500,000 和 $1,000,000 放在一起，后者是前者的两倍。但两家公司的收入不同，保额的相对大小要放回各自收入里看。

Nord 的 3.24 倍意味着：如果一次 E&O 索赔把保额全部用完，相当于公司三年多的收入被一次性索赔吃掉。LedgerLite 的 4.16 倍更厚，但网络安全事件的响应成本也可能更高：取证、通知、法律抗辩、客户补偿可以同时发生。倍数只说明保额相对收入的大小，不说明事故的概率，也不说明保额一定够。

把保额和卷二前面算过的责任上限放在一起，会看得更清楚。LedgerLite 的合同责任上限是 12 个月费用 $240,240；网络安全险 $1,000,000 是它的 4.16 倍。Nord 的咨询合同上限是合同金额 100%，E&O $500,000 是年收入的 3.24 倍。LedgerLite 的上限覆盖的是「一年收入」级别的事故，Nord 的 E&O 覆盖的是「三年收入」级别的事故；但两者的保单都可能把某些索赔排除在外，所以倍数只描述上限，不描述实际赔付。责任上限的算法见2.1 责任上限：最坏损失怎么算 。

最后两行是近似：Nord 的合同上限是「合同金额 100%」，没有披露平均合同期，所以用年收入做分母；LedgerLite 的三年上限在 2.1 节算过是 $720,720。这个近似不影响结论：保额相对一年期上限很厚，相对三年期上限就没有那么厚。

保额倍数还有一个分母选择问题：用年收入、SDE 还是合同上限。三个分母回答三个不同问题。用年收入，回答「保额相当于几年生意」；用 SDE，回答「一次索赔相当于几年可支配收益」；用合同上限，回答「保额能不能盖住合同最坏损失」。同一张保单，三个倍数可能差很多。Nord 的 E&O 相对年收入是 3.24 倍，相对 SDE $34,320 是 14.57 倍；LedgerLite 的网络安全险相对年收入是 4.16 倍，相对 SDE $130,240 是 7.68 倍。倍数越大，说明保额相对该分母越厚；但分母选错，结论就会失真。

这张表不是让读者挑一个最大的倍数来安心，而是说明「保额够不够」必须先定义分母。对合同谈判，分母是合同上限；对生存分析，分母是 SDE；对市场比较，分母是年收入。三个问题不能用一个倍数回答。

保费买到的覆盖倍数

保费是保险的价格，但直接比较 $4,800 和 $4,800 没有意义，因为两家公司的保额不同。把保额除以保费，得到每 $1 保费买到的保额：

网络安全险的杠杆更高，不代表它更划算。保费反映的是保险公司对事故概率、响应成本和条款宽窄的判断；保额高、保费低，可能意味着免赔额更高、分项限额更窄、除外责任更多。只看每美元买到多少保额，会漏掉这三项。免赔与除外责任的算法在6.2 保额、免赔与除外责任 。

还有一个更重要的比较：保费占收入的比例，和一次未保险损失占 SDE 的比例。Nord 的 SDE 是 $34,320，$4,800 保费占 SDE 的 14.0%；一次 $120,000 的未保险索赔是 SDE 的 3.50 倍。LedgerLite 的 SDE 是 $130,240，$4,800 保费占 SDE 的 3.7%；一次 $120,000 的未保险索赔是 SDE 的 0.92 倍。同样是 $4,800 保费，对 Nord 的利润压力远大于对 LedgerLite；同样是一次 $120,000 的损失，对 Nord 的生存威胁也远大于对 LedgerLite。

这张表说明，保险预算不能按「收入的百分比」一刀切。同样的保费率，对低 SDE 的服务型公司更重；同样的保额，对高 SDE 的订阅公司更轻。选择保额时，分母应该是一次事故能让公司损失多少，而不是同行买了多少。

保费的绝对额还会影响现金流。Nord 的可支配现金是 $25,740，$4,800 保费占 18.6%；LedgerLite 的经营现金流是 $64,299，$4,800 保费占 7.5%。保险通常按年或按季预付，不能在事故后才付；对现金流紧的公司，保费本身就是一个需要排期的现金支出。把保费放进 13 周现金表，和把保额放进风险预算，是两件不同的事，但都要做。

代码：把保额换算成覆盖倍数

下面的 insurance.ts 把三类险统一成同一组字段：年收入、保额、年保费，输出覆盖倍数和保费率。describePolicy 处理单张保单，combinePolicies 把多张保单加总成一个预算视图。金额用整数美分，比率用基点。

// file: src/contract/insurance.ts
// tier: L1
// verify: node --test test/contract/insurance.test.ts

import { type Cents } from "../core/money.ts";
import { type Bps, divide } from "../core/rate.ts";
import { type Result, fail, ok } from "../core/result.ts";

export type PolicyKind =
  | "professional-liability"
  | "cyber"
  | "employers-liability";

export type PolicyInput = {
  kind: PolicyKind;
  annualRevenueCents: Cents;
  limitCents: Cents;
  annualPremiumCents: Cents;
};

export type Policy = {
  kind: PolicyKind;
  annualRevenueCents: Cents;
  limitCents: Cents;
  annualPremiumCents: Cents;
  coverageMultipleBps: Bps;
  premiumRateBps: Bps;
};

export type PortfolioInput = {
  annualRevenueCents: Cents;
  policies: PolicyInput[];
};

export type Portfolio = {
  annualRevenueCents: Cents;
  totalLimitCents: Cents;
  totalPremiumCents: Cents;
  combinedCoverageMultipleBps: Bps;
  premiumLoadBps: Bps;
};

const KINDS: PolicyKind[] = [
  "professional-liability",
  "cyber",
  "employers-liability",
];

function validPolicy(input: PolicyInput): string | null {
  if (!KINDS.includes(input.kind)) {
    return "unknown policy kind";
  }
  if (
    !Number.isInteger(input.annualRevenueCents) ||
    input.annualRevenueCents <= 0
  ) {
    return "annual revenue must be a positive integer amount in cents";
  }
  if (!Number.isInteger(input.limitCents) || input.limitCents < 0) {
    return "policy limit must be a non-negative integer amount in cents";
  }
  if (
    !Number.isInteger(input.annualPremiumCents) ||
    input.annualPremiumCents < 0
  ) {
    return "annual premium must be a non-negative integer amount in cents";
  }
  return null;
}

/**
 * The limit is quoted as an absolute amount, but the number that matters for a
 * small business is how many years of revenue it represents. Coverage multiple
 * and premium load put every policy on the same scale before comparing types.
 */
export function describePolicy(input: PolicyInput): Result<Policy> {
  const error = validPolicy(input);
  if (error) {
    return fail(error);
  }

  return ok({
    kind: input.kind,
    annualRevenueCents: input.annualRevenueCents,
    limitCents: input.limitCents,
    annualPremiumCents: input.annualPremiumCents,
    coverageMultipleBps: divide(input.limitCents, input.annualRevenueCents),
    premiumRateBps: divide(input.annualPremiumCents, input.annualRevenueCents),
  });
}

/**
 * Limits from different policies are not additive in real claims: a cyber
 * event is not paid from the professional liability limit. Combining them here
 * is a budgeting view that answers what the total purchased limit and total
 * premium load are, not a statement that one event can draw on every policy.
 */
export function combinePolicies(input: PortfolioInput): Result<Portfolio> {
  if (
    !Number.isInteger(input.annualRevenueCents) ||
    input.annualRevenueCents <= 0
  ) {
    return fail("annual revenue must be a positive integer amount in cents");
  }

  let totalLimitCents = 0;
  let totalPremiumCents = 0;
  for (const policy of input.policies) {
    const error = validPolicy(policy);
    if (error) {
      return fail(error);
    }
    if (policy.annualRevenueCents !== input.annualRevenueCents) {
      return fail("policy revenue does not match portfolio revenue");
    }
    totalLimitCents += policy.limitCents;
    totalPremiumCents += policy.annualPremiumCents;
  }

  return ok({
    annualRevenueCents: input.annualRevenueCents,
    totalLimitCents,
    totalPremiumCents,
    combinedCoverageMultipleBps: divide(
      totalLimitCents,
      input.annualRevenueCents,
    ),
    premiumLoadBps: divide(totalPremiumCents, input.annualRevenueCents),
  });
}

代码里有两个口径需要说明。第一，coverageMultipleBps 是保额除以年收入，不是保额除以 SDE；它回答「保额相当于几年收入」，不回答「够不够赔」。第二，combinePolicies 把不同险种的限额相加，只是为了看总预算，不代表一次事故可以从每张保单各取一次限额；真实理赔按险种分别计算，不能横向挪用。

combinePolicies 还校验每张保单的收入与组合收入一致。这个校验看起来多余，但它防的是一个常见错误：用集团收入买保单，却用单实体收入做预算。分子分母口径不一致，覆盖倍数就没有意义。

Nord、LedgerLite 与 Tidecast 的对照

Nord 的 E&O 覆盖倍数 3.24 倍，保费占收入 3.11%，占 SDE 14.0%。对两位合伙人、服务收入占 72.7% 的生意，E&O 是最贴近主营风险的险种；但它只保专业服务出错，不保客户数据泄露，也不保雇佣争议。Nord 招聘第三人之后，雇主责任险才从不相关变成需要算一算。

LedgerLite 的网络安全险覆盖倍数 4.16 倍，保费占收入 2.00%，占 SDE 3.7%。它的主营风险是客户财务数据，网络安全险比 E&O 更贴近；但保单里的通知费用分项限额、免赔额和除外责任，会把 4.16 倍的名义覆盖打折扣。DPA 下的责任怎么分配，见11.1 DPA、SCC 与跨境传输 。

Tidecast 没有保险，平台发行协议又把一部分风险转移给平台；但 IP 授权和音乐买断授权带来的第三方索赔，仍然由自己承担。对年净得 $138,171 的一个人公司，第一笔未保险损失就是全自留。

小结

• 三类险保的是三种不同的事故：E&O 保专业服务出错，网络安全险保数据与系统事件，雇主责任险保雇佣关系。
• Nord 的 E&O $500,000 是年收入 $154,320 的 3.24 倍；LedgerLite 的网络安全险 $1,000,000 是年收入 $240,240 的 4.16 倍。
• 保额倍数只描述相对规模，不描述实际赔付；分项限额、免赔额和除外责任会把名义覆盖打折。
• 每 $1 保费买到的保额，网络安全险是 208.3 倍，E&O 是 104.2 倍；杠杆更高不代表条款更宽。
• 保费占 SDE 的比例比保费占收入的比例更能说明压力：Nord 是 14.0%，LedgerLite 是 3.7%。
• 一次 $120,000 的未保险损失，对 Nord 是 3.50 年 SDE，对 LedgerLite 是 0.92 年 SDE；同一个金额，生存威胁完全不同。
• 险种名字不是覆盖范围；判断一张保单保不保，要看定义、除外责任、分项限额和追溯日。

阅读导航：上一节：5.3 证据链与止损 · 下一节：6.2 保额、免赔与除外责任 。

常见错误与边界

1. 把 E&O 当成万能险。 E&O 保专业服务出错，通常不保数据泄露、勒索软件和雇佣争议；三类险的边界要在保单里逐条核对。
2. 把网络安全险当成数据泄露的全额赔付。 通知费用、取证费用、法律抗辩可能各有分项限额；总保额 $1,000,000 不等于每项都能赔到 $1,000,000。
3. 只看保额，不看年收入。 $500,000 对年收入 $154,320 是 3.24 倍，对年收入 $1,500,000 只有 0.33 倍；保额要放回收入里看。
4. 只看保费，不看 SDE。 同样 $4,800 保费，对 Nord 是 SDE 的 14.0%，对 LedgerLite 是 3.7%；压力完全不同。
5. 用每美元保额判断划算。 杠杆高可能是免赔高、分项窄、除外多；保费低不等于保障好。
6. 把多张保单的限额相加当成一次事故的可用额度。 不同险种分别理赔，限额不能横向挪用；加总只能做预算视图。
7. 忽略雇主责任险的触发条件。 没有员工时它不相关；招聘第三人之后，工伤和雇佣争议才进入范围，要重新算保费。
8. 把保险当成责任上限的替代品。 保险不改变合同上你欠对方多少钱，只改变谁支付；责任上限仍然要单独谈。
9. 忽略追溯日。 E&O 和网络安全险常按索赔发生制承保；事故发生在追溯日之前，保单可能不赔。
10. 用同行保额代替自己的计算。 同行收入、SDE、事故概率都不同；保额倍数要按自己的分母算。

保险的财务作用，是把「一次事故最多赔多少」从合同条款延伸成「一次事故最多自留多少」。下一节把保额、免赔和除外责任放进同一个赔付公式，算清楚名义保额最后能变成多少现金。