Insurance Coverage Statement

Last reviewed: 2026-05-11. Owner: David McHale (CEO function).

Audience: Procurement reviewers, contract administrators, customer risk-management teams.

Purpose: State current and in-progress insurance coverage. HailBytes’ coverage strategy is sized to its actual risk surface, which the BYOC architecture materially shrinks. This document explains both the limits and the rationale, so procurement reviewers can evaluate appropriateness rather than reflexively compare against multi-tenant-SaaS-vendor benchmarks.

1. Coverage philosophy and the BYOC adjustment

The single biggest driver of cyber-liability premium for a security vendor is the size of the data-loss exposure if the vendor itself is compromised. For a multi-tenant SaaS vendor, that exposure is “every customer’s data in one breach” — and premium pricing reflects it.

HailBytes’ BYOC architecture (byoc-architecture.md) materially changes this calculation:

  • HailBytes does not hold customer-scanned data, customer employee lists, customer phishing-campaign results, or customer audit logs. A breach of HailBytes’ own infrastructure does not produce a multi-tenant data-loss event.
  • A single-customer compromise is structurally constrained to that customer’s tenant; HailBytes is not the single-point-of-compromise target.
  • HailBytes’ realistic incident exposures are: support-ticket contents (limited PII volume), marketing-list contacts (low sensitivity), and Marketplace settlement metadata (commercial, not personal-sensitive at scale).

The coverage levels in §2 are sized to this actual surface, not to a comparable multi-tenant-SaaS-vendor benchmark. A procurement reviewer comparing HailBytes’ limits to a SaaS competitor’s limits should weigh the structural data-residency posture as the offsetting factor.

For customers whose own procurement floors require higher named limits than HailBytes carries by default, HailBytes will obtain per-customer endorsements (additional-insured + bumped policy limit for the duration of the contract) at the customer’s incremental premium cost. This is offered as a standard contract negotiation item.

2. Coverage status

HailBytes is in an active broker bind cycle. Application submitted 2026-05-11; target effective date 2026-05-15. Until bind confirmation is received, a quote letter from Vouch showing bound limits contingent on signed contract is available on request from contracts@hailbytes.com — this is commonly accepted by enterprise procurement as an interim artifact. See §3 for details.

3. In progress — Vouch, three policies at $1M, target effective 2026-05-15

Primary broker: Vouch (vouch.us). HailBytes submitted the Vouch application on 2026-05-11 covering General Liability, Technology Errors & Omissions, and Cyber Liability in a single package, each at the $1,000,000 limit described below. Target effective date: Friday 2026-05-15. Coalition (coalitioninc.com) and Embroker (embroker.com) remain on standby if Vouch’s terms are not competitive.

3.1 General Liability

  • Target limit: $1,000,000 per occurrence / $1,000,000 aggregate.
  • Status: Vouch application submitted 2026-05-11.
  • Target effective date: 2026-05-15.

3.2 Technology Errors & Omissions (Tech E&O)

  • Target limit: $1,000,000 per claim / $1,000,000 aggregate. Per §1, sized to HailBytes’ actual realized E&O exposure under BYOC delivery.
  • Status: Vouch application submitted 2026-05-11.
  • Target effective date: 2026-05-15.
  • Per-customer endorsement available for procurement floors that require higher named limits.

3.3 Cyber Liability

  • Target limit: $1,000,000 per claim / $1,000,000 aggregate. Per §1, sized to HailBytes’ actual cyber-incident exposure under BYOC delivery (no multi-tenant data aggregate).
  • Status: Vouch application submitted 2026-05-11.
  • Target effective date: 2026-05-15.
  • Per-customer endorsement available for procurement floors that require higher named limits or expanded scope (regulatory defense costs, business-interruption coverage extensions).

3.4 Combined premium envelope

The $1M / $1M / $1M baseline across all three policies is sized to HailBytes’ actual exposure under the BYOC architecture — materially smaller than a comparable multi-tenant SaaS vendor’s exposure because there is no multi-tenant data aggregate to lose. This is a structural difference, not a corner-cutting choice.

4. Additional coverage under consideration

  • Directors & Officers (D&O): typically deferred until Series A or first institutional capital event; not currently required by any enterprise contract under negotiation.
  • Workers’ Compensation: in place per applicable jurisdiction(s); details available on request.
  • Employment Practices Liability: in place where required.

5. Customer name on COI

For named enterprise customers, HailBytes will list the customer as an “additional insured” on the bound Tech E&O and Cyber Liability policies where the policy permits, at the customer’s request. This is routine for tech-native brokers.

6. Per-customer endorsement option

If a customer’s procurement policy requires named limits above the baseline in §3 (commonly $2M E&O / $5M Cyber for IBM-class enterprises), HailBytes will negotiate a per-customer endorsement at the customer’s incremental premium cost. The premium delta is passed through transparently. This avoids carrying excess coverage broadly to satisfy a narrow set of procurement floors, while making the option available to any customer that requires it.

7. Notification on policy lapse

HailBytes commits to notifying the customer’s named contracts contact within 5 business days of any non-renewal, cancellation, or material reduction in coverage for any policy named on the COI provided to the customer.

8. Document lifecycle

  • COIs are reissued annually on policy renewal; superseded COIs are retained in the contracts repository.
  • This document is updated within 5 business days of any change in coverage. Version history is the audit trail.

Cross-references: compliance-roadmap.md §6 for the bind-date commitment in §3; byoc-architecture.md for the structural argument behind §1; key-person-succession.md §1 for the CEO function (David McHale) that owns this document.