Business continuity plan

<h2>Objective</h2> <p>Maintain the HiringCoachAI service for users and customers during disruption to people, technology, or third-party services. Keep customer data safe and recoverable throughout.</p> <h2>Business impact</h2> <table><thead><tr><th>Function</th><th>Tolerable downtime</th><th>Tolerable data loss</th></tr></thead><tbody><tr><td>Authentication (signin, signup)</td><td>4 h</td><td>0</td></tr><tr><td>Customer-facing web app</td><td>4 h</td><td>0</td></tr><tr><td>Resume / cover-letter generation (AI)</td><td>8 h</td><td>0</td></tr><tr><td>Payment processing (Stripe)</td><td>4 h</td><td>0</td></tr><tr><td>Transactional email (SendGrid)</td><td>8 h</td><td>0</td></tr><tr><td>Admin tooling</td><td>24 h</td><td>0</td></tr><tr><td>Analytics ingestion</td><td>7 d</td><td>7 d</td></tr></tbody></table> <p>These inform the RTO (Recovery Time Objective) and RPO (Recovery Point Objective) in <a href="/trust/docs/drp">disaster recovery plan</a>.</p> <h2>Key dependencies</h2> <table><thead><tr><th>Dependency</th><th>Role</th><th>Failure impact</th><th>Alternative</th></tr></thead><tbody><tr><td>Vercel</td><td>Application hosting</td><td>App unreachable</td><td>Fail over to Firebase Hosting (static) + direct Cloud Functions (documented in DRP)</td></tr><tr><td>Firebase Auth</td><td>Authentication</td><td>No signin</td><td>No alternative (re-provision in another GCP project in worst case)</td></tr><tr><td>Firestore</td><td>Primary database</td><td>No reads/writes</td><td>Restore from backup to new Firestore project</td></tr><tr><td>Cloud Storage</td><td>Coach/client materials, chat attachments, profile images, account/resume files, backup/export buckets, and Cloud Functions source buckets</td><td>Material upload, preview, and download workflows plus other storage-backed workflows are unavailable; Firestore metadata remains intact</td><td>Restore service or affected objects in an alternate bucket/region and update the server-side bucket configuration</td></tr><tr><td>Stripe</td><td>Payments</td><td>No new subscriptions; existing charges continue</td><td>Payments pause with customer notice</td></tr><tr><td>SendGrid</td><td>Email</td><td>Magic-link signin &amp; notifications fail; in-app still works</td><td>Failover to AWS SES or Resend (requires DNS change + template migration)</td></tr><tr><td>OpenAI (called both directly and via Vercel AI Gateway)</td><td>AI generation</td><td>AI features degraded</td><td>Vercel AI Gateway provides a routing layer to alternate AI providers; failover would require code/config changes plus DPA execution and sub-processor inventory update for any new provider before production traffic flows</td></tr><tr><td>Deepgram</td><td>Transcription</td><td>Voice features disabled</td><td>Queue for later or switch to Google STT</td></tr><tr><td>ElevenLabs</td><td>Speech synthesis</td><td>Voice features disabled</td><td>Google TTS fallback already wired</td></tr><tr><td>DNS (Namecheap/Cloudflare)</td><td>Resolution</td><td>Site offline</td><td>Alternate registrar record + longer TTL</td></tr></tbody></table> <h2>Activation triggers</h2> <p>The Security Officer activates the BCP when any of:</p> <ul><li>Customer-facing downtime exceeds 1 h</li><li>Data loss is confirmed or suspected</li><li>Security incident at Severity 1 or 2 (per <a href="/trust/docs/incident-response">incident response</a>)</li><li>Loss of access to production systems</li><li>Natural disaster or personnel incident affecting the Security Officer</li></ul> <h2>Response structure</h2> <table><thead><tr><th>Role</th><th>Responsibility</th></tr></thead><tbody><tr><td><strong>Incident Commander</strong></td><td>Security Officer. Coordinates response, declares severity, authorizes customer comms.</td></tr><tr><td><strong>Technical Lead</strong></td><td>Diagnoses, orchestrates recovery.</td></tr><tr><td><strong>Communications Lead</strong></td><td>Updates status page, sends customer comms. Often same person as IC in small-team mode.</td></tr></tbody></table> <p>Contact info and escalation paths are maintained in an internal on-call register; the current Incident Commander is reachable at <code>[email protected]</code>.</p> <h2>Communications</h2> <ul><li><strong>Status-page update target:</strong> within 30 minutes of a declared incident (<code>hiringcoach.ai/status</code>).</li><li><strong>Customer email:</strong> Sent via backup SES/Resend channel if SendGrid is the failing dependency.</li><li><strong>Regulatory:</strong> Per <a href="/trust/docs/breach-notification">breach notification</a> if personal data is affected.</li></ul> <h2>Continuity of operations</h2> <ul><li>All source of truth lives in git (policies, config, code).</li><li>Firestore PITR, managed daily Firestore backups with 98-day retention, and US multi-region backup/export bucket evidence are retained in the restricted continuity evidence set.</li><li>Business-continuity recovery relies on documented continuity procedures, recovery materials version-controlled in git, and the Incident Commander role defined in this plan.</li></ul> <h2>Testing</h2> <ul><li><strong>Quarterly:</strong> Tabletop scenario review (15 min, Security Officer with any additional engineer available).</li><li><strong>Annually:</strong> Full restore drill (logged in DRP).</li><li><strong>Post-incident:</strong> Plan update within 30 days.</li><li><strong>Weekly / on demand:</strong> an automated continuity evidence bundle runs on a scheduled workflow or on demand. It exercises BCP/DRP documentation reviews, a synthetic safe restore drill, public health probes, and optional read-only Google Cloud backup checks when credentials are available; results are archived in the internal drill evidence set. This complements (does not replace) the human tabletop and full live restore/failover drills.</li></ul> <h2>Last-drill log</h2> <table><thead><tr><th>Date</th><th>Scope</th><th>Outcome</th><th>Record</th></tr></thead><tbody><tr><td>2026-04-24</td><td>Targeted Firestore PITR restore to staging (single collection, DRP-linked continuity restore drill)</td><td>PASS: partial-scope RTO 47 min; RPO 30 min</td><td>Internal drill record</td></tr><tr><td>2026-05-02</td><td>Documentation-review tabletop (automated)</td><td>PASS: 23/23 checks</td><td>Internal drill record</td></tr><tr><td>2026-05-14</td><td>Automated continuity evidence bundle</td><td>PASS: 0 blocking failures across BCP and DRP documentation checks, synthetic restore, HECVAT caveat check, and read-only health probes</td><td>Internal drill record</td></tr><tr><td>2026-05-19</td><td>Automated continuity evidence bundle</td><td>PASS: 0 blocking failures across BCP and DRP documentation checks, synthetic restore, HECVAT caveat check, and read-only public health probes; no production writes performed</td><td>Internal drill record</td></tr></tbody></table> <p>Each drill appends a row here. The automated runner verifies BCP sections, cross-reference resolution, and dependency-list parity with the <a href="/trust/docs/sub-processors">sub-processors</a>. Targeted restore drills, human tabletop sessions, and full live failover exercises are tracked here too with their own dated records.</p> <h2>Resumption</h2> <p>An &quot;all clear&quot; is declared by the Incident Commander when: 1. Service is restored. 2. Data integrity verified. 3. Root cause understood. 4. Short-term mitigation in place.</p> <p>Long-term remediation is tracked in the post-mortem (see <a href="/trust/docs/incident-response">incident response</a>).</p> <h2>Related</h2> <ul><li><a href="/trust/docs/drp">disaster recovery plan</a>: technical recovery procedures</li><li><a href="/trust/docs/incident-response">incident response</a>: severity levels, comms, post-mortems</li><li><a href="/trust/docs/breach-notification">breach notification</a>: regulatory timelines</li></ul>