Key-Person Risk and Succession Plan

Owner: HailBytes CEO function. Last reviewed: 2026-05-10. Annual review date: 2027-05-10 and each anniversary thereafter.

Audience: Procurement reviewers assessing key-person concentration risk in a small-vendor relationship.

Purpose: Document who holds which production access and customer-facing responsibility at HailBytes, who can step in if any of them is unavailable, and what response times the company commits to for incident scenarios that intersect with key-person availability.

This document names real individuals. Updates to named roles are reviewed annually and on any role change.

1. Role concentration today

HailBytes is a small, bootstrapped company. Honest framing: today the company has fewer than ten people, and several production-critical capabilities concentrate on the CEO and CTO functions. The purpose of this plan is to make that concentration legible, document mitigations that are already in place, and commit to dated reductions in concentration as the company grows.

HailBytes’ current operating reality: David McHale holds three of the four primary roles, so the named successors carry the practical bus-factor weight. John Shedd is the commercial-and-support successor; Boden McHale is the technical successor. This concentration is documented honestly rather than papered over. The hiring milestones in compliance-roadmap.md §9 reduce concentration over the 2026–2027 window.

2. Production access map

Key invariants:

• No single individual is the only person with admin access to any critical system.
• All elevated access is SSO-mediated with MFA required; no shared passwords.
• The Sigstore signing identity is bound to the GitHub Actions OIDC token, not to a human-held key. There is no signing key that can be lost with an individual.

3. Customer relationship continuity

For each named enterprise customer (current: IBM Brazil, HEANet, Convatec, and any future enterprise account), HailBytes maintains:

• A primary commercial contact (CEO function).
• A designated technical escalation contact (CTO function).
• A backup commercial contact (CEO successor per §1).
• A backup technical contact (CTO successor per §1).

All four are recorded in the customer’s contract or in the support-hub customer record. The customer can reach any of the four through the documented channels.

4. Incident scenarios with named responders

4.1 24-hour scenario: David McHale unavailable

Example: David incapacitated, on extended leave, or otherwise unreachable for up to 24 hours.

• Commercial relationships: John Shedd handles inbound enterprise inquiries and continues conversations in flight.
• Contract signing: John Shedd has signing authority up to $50,000 per contract; over $50,000, contracts pause for David’s availability so he can confirm fulfillment terms before signature.
• Marketplace listing changes: John Shedd has publisher access on both AWS and Azure Marketplace; Boden McHale has GitHub org admin and can ship technical changes independently.
• Release pipeline: unaffected (Boden McHale retains independent GitHub org admin; Sigstore signing identity is OIDC-bound and not tied to any individual).
• [email protected] triage: Boden McHale covers inbox triage; coordinated disclosure window pauses for up to 48 hours of David unavailability without breaching the documented 90-day SLA.

4.2 72-hour scenario: David McHale unavailable during a security incident

The compound scenario: David is the primary across CEO, CTO, and Security lead roles; a 72-hour absence during an active incident is the worst plausible single-person scenario.

• Incident response: Boden McHale is incident commander; John Shedd is the customer-communication channel and authorizes any commercial-impact decisions.
• Release pipeline: Boden ships any required security patch from a clean commit through the existing CI/CD; the standard two-reviewer code-review requirement is met by Boden + John Shedd (read-only commercial review for change-control awareness) for the duration of David’s absence.
• Sigstore signing: unaffected (OIDC-bound, not human-held).
• Customer-facing communication: John Shedd is the customer-facing voice; Boden provides the technical content.

4.3 30-day scenario: David McHale, John Shedd, or Boden McHale permanently lost

• David permanently lost: John Shedd assumes CEO function; Boden McHale assumes CTO and Security lead functions on an interim basis. Permanent succession decisions confirmed within 30 days. Customers notified within 5 business days of permanent confirmation. The release pipeline continues to operate throughout because no single human is in the critical path of release signing.
• John permanently lost: David retains CEO function; a new commercial successor is named within 30 days. Customer relationships continue under David’s primary contact.
• Boden permanently lost: David retains CTO and Security lead functions; a new technical successor is named within 30 days. Hiring milestones in compliance-roadmap.md §9 accelerate.
• Bus-factor exit: if all three of David, John, and Boden are simultaneously lost (vanishingly low probability), the surviving HailBytes corporate entity has access to all version-controlled documentation, IaC, and source code. The product continues running in customer deployments without HailBytes-side intervention (see bcp-dr-plan.md §5). Customer contracts continue under the corporate entity, not the individuals.

5. Continuity of HailBytes’ open-source posture

A specific note: HailBytes ASM and SAT are open-source under MIT-style licenses. In the worst case of complete corporate failure, the customer is not dependent on any HailBytes individual for continued use of the deployed software. See bcp-dr-plan.md §5.

6. Annual review and update

This document is reviewed annually on the anniversary date noted at the top, and out-of-band whenever one of the named individuals changes role or leaves the company. Updates are committed to the trust-package repository so the version history is the audit trail.

Cross-references: bcp-dr-plan.md §2.6 for the wider continuity context; compliance-roadmap.md for the hiring milestones that will reduce concentration.