Business Continuity Plan
Organization: Strategic Habits Consulting, LLC (DBA Gevell) Plan owner: Larry Anglin, CTO Review cycle: Annually, with a tabletop test (see §8) Related: Disaster Recovery Plan, Incident Response Plan
1. Purpose
This plan describes how Gevell keeps serving customers through disruptions, including the unavailability of a key person. Gevell has two people. The plan is sized for that. We describe what exists today and what we commit to, and the items not yet done are listed at the end.
2. Company profile
| Item | Detail |
|---|---|
| Legal entity | Strategic Habits Consulting, LLC, doing business as Gevell |
| People | Larry Anglin, CTO: engineering and operations, the only person with production access. Laura Hopkins, Chief Accessibility Officer: customer relationships, accessibility expertise, no production access |
| Service | SaaS document-accessibility conversion and auditing (Gevell PDF, Gevell Audit, and related apps) |
| Availability commitment | 99.5% monthly (SLA) |
| Insurance / retainers | No cyber-liability insurance. No external incident-response retainer |
3. Critical business functions
| # | Function | Why it matters | Max tolerable disruption (target) | Depends on |
|---|---|---|---|---|
| F1 | Document upload, conversion and download | The core service customers pay for | 24 h | Cloudflare (Pages, R2, Tunnel), AWS (Lambda, SQS, Bedrock, EC2 processing host), Supabase |
| F2 | Customer sign-in and account access | Needed to reach stored documents | 24 h | Supabase Auth, Cloudflare, email delivery (Resend) for magic links and OTP |
| F3 | Protecting customer data (confidentiality and integrity) | Contractual, FERPA, trust | Never suspended | All of the above, plus access controls and monitoring |
| F4 | Customer communication and support | Customers must know status and have a contact | 1 business day | Email (company mailboxes), status.gevell.com, Laura |
| F5 | Billing and payments | Revenue. Prepaid credits enable use | 5 business days | Stripe, Supabase ledger |
| F6 | Monitoring and alerting | Detecting problems quickly | 24 h | Health-monitor daemons, Amazon CloudWatch Logs and alarms, AWS GuardDuty, status.gevell.com, Telegram, Resend |
| F7 | Software maintenance and security patching | Keeping the platform secure | 7 days (critical security fixes: see IR plan) | GitHub, CI runners, Larry |
Recovery-time and data-loss targets for each technical system are in the DR plan §3.
4. Dependencies
| Dependency | Used for | If it fails | Continuity measure |
|---|---|---|---|
| AWS (us-east-1) | Lambda API, EC2 processing host (Node API + processing), SQS queues, S3 staging, Bedrock AI inference | Processing service unavailable during a regional outage | Provider SLA; redeploy from CDK; DR §5.1 |
| Cloudflare | Frontends, CDN, R2 document storage, Tunnel to the Node API, status page | Whole customer-facing service unavailable | Provider SLA; no alternate CDN (accepted risk); communicate by email |
| Supabase (us-east-2) | Database, authentication | Service fails closed (no sign-in, no job state) | Provider daily backups; DR §5.2 |
| Stripe | Payments | New purchases unavailable. Existing credits still usable | Stripe is the system of record. Invoice manually if prolonged |
| Resend | Transactional email (sign-in links, notifications) | Magic-link / OTP sign-in and notifications delayed | Customers with password sign-in unaffected. Laura sends urgent notices from company mailboxes |
| AWS EC2 “anchor” (us-east-1: fixed-size Auto Scaling group across 2 AZs, reached through an outbound-only Cloudflare Tunnel) | Node API (api.theaccessible.org) and heavy document processing | Node API routes and processing are briefly unavailable. Queued work waits in the queue and resumes on the replacement instance | The Auto Scaling group replaces a failed instance automatically (target 1 h); DR §5.4 |
| GitHub | Source code, CI/CD | Cannot ship changes through the normal path | Nightly backup to R2; local clones; manual deploys (DR §5.7) |
| Backblaze B2 | Encrypted backups of ops data and operator secrets | Backups pause | Alerting on stale backups; not in the live service path |
| Mathpix | Math OCR for some documents | Math-heavy conversions degrade | Other conversion paths continue | | Telegram / email | Operator alerting | Delayed detection | Redundant channels (email + Telegram) |
| Operator workstation (Larry’s Mac) | Admin work, some scheduled jobs | Admin tasks delayed | Config and secrets backed up nightly (encrypted); SSO works from any device |
5. Key-person risk
Current position: Larry Anglin is the single operator and the only person with production access. The platform is highly automated. Queues retry, failover capacity scales on its own, and monitoring alerts automatically. It keeps running without daily human input. But any repair, deploy, security response or credential rotation needs Larry today.
5.1 If Larry is unavailable
| Duration | What happens | Who acts |
|---|---|---|
| Up to 24 h (travel, illness) | The service runs unattended. Alerts wait | Laura handles customer contact and posts status updates if customers report problems (see §6) |
| 1–7 days | Laura tells affected customers there is a support delay. No production changes are made. If there is an active outage or security event, Laura contacts the backup technical responder (designated; contact details held by Larry and Laura, not recorded here) | Laura |
| More than 7 days, or permanent (incapacity or death) | Laura invokes the break-glass procedure (below). The backup technical responder uses it to keep the service running, rotate credentials, or carry out an orderly wind-down with data return to customers | Laura + backup technical responder |
5.2 Break-glass kit (being established)
- Sealed envelope stored in a locked location that Laura can reach, with a second copy with the company’s attorney or another designated custodian. It gives access to a dedicated password-manager emergency vault holding the credentials and MFA recovery codes for every production account, and an index of the operating runbooks.
- Vault: 1Password emergency kit or emergency-access grant. Holds the AWS root credentials, Cloudflare, Supabase, GitHub, Stripe, domain registrar and email-admin credentials, with MFA recovery codes.
- Runbook index: this plan, the DR plan, the IR plan,
docs/admin/access/aws-access.md,docs/admin/security/secrets-inventory-and-rotation.md, the AI kill-switch runbook.
- Tamper evidence: the envelope is signed across the seal. Its contents are re-checked and it is re-sealed at every annual test.
- Use is logged. After any use, every credential in the kit is rotated.
- Laura does not use production credentials herself. She is authorized to release the kit to the designated backup technical responder.
5.3 Documented runbooks (in place)
Operational procedures are written down in our internal operations documentation. This includes deployment, processing-host failover and rebuild, AWS access and break-glass IAM user, secrets inventory and rotation, AI kill switch, backup status, and health monitoring. A competent engineer holding the break-glass kit can operate the platform from these documents.
6. Communication plan
| Audience | Channel | Owner | When |
|---|---|---|---|
| All customers | status.gevell.com | Larry (Laura may request posts) | Within 1 h of confirming a customer-visible outage. Updated at least every 4 h until resolved |
| Affected institutional customers (named contacts, security contacts) | Direct email from company mailboxes (larry@gevell.com, Laura’s address). These do not depend on the product’s Resend setup | Laura | Within 4 business hours for outages longer than 1 h. Security incidents follow IR plan §6 |
| Individual users | In-app banner or email via Resend, if available | Larry | As needed |
| Providers | Provider support channels (IR plan §10) | Larry | Immediately, when a provider is the cause |
Message content: what is affected, when it started, what customers should do (for example, “retry later; no need to re-upload”), whether data is affected, and when the next update will come.
If Cloudflare is down, status.gevell.com is also unavailable. Use direct email.
7. Wind-down / continuity of customer data
If the company cannot continue operating, customers get at least 30 days’ notice where possible. They can download their documents during that time. Customer data is then deleted according to the retention terms in the customer agreement. Deletion is confirmed in writing on request.
8. Annual tabletop test
Frequency: Once every 12 months (and after a major change). Participants: Larry, Laura and the backup technical responder. Duration: About 2 hours. Facilitator: alternates between Larry and Laura.
Status: no annual BCP test has been performed and recorded yet.
8.1 Procedure
- Pick one or two scenarios (rotate them each year):
- A. Larry is unreachable for 10 days during an active outage.
- B. Cloudflare has an 8-hour global outage during a customer’s semester-start deadline.
- C. Supabase data loss requiring restore from the daily backup (DR §5.2).
- D. The EC2 anchor instance is lost or compromised (DR §5.4 / §5.6).
- Walk through the scenario step by step using this plan and the DR plan. At each step, ask: who acts, with what access, using which document?
- Break-glass check (every year): open and inspect the sealed kit (without logging in to production). Confirm the vault access works and the index is current. Re-seal and record the seal date.
- Check that contact lists and the customer contact list are current.
- Record the results in the log below. Turn every gap into an action with an owner and a due date.
- Update this plan and its revision date.
8.2 Test log (template)
| Date | Scenario(s) | Participants | Break-glass kit checked / re-sealed (Y/N, seal date) | What worked | Gaps found | Actions (owner, due) | Plan updated (Y/N) |
|---|---|---|---|---|---|---|---|
| YYYY-MM-DD |
Actions required before this plan is true
| # | Action | Owner |
|---|---|---|
| BCP-0 | Complete the AWS EC2 deployment of the Node API and processing workload (DR plan action DR-1) | Larry |
| BCP-1 | Larry | |
| BCP-2 | Create the break-glass vault and sealed envelope (§5.2): credentials, MFA recovery codes, runbook index. Deposit the second copy with a custodian | Larry |
| BCP-3 | Give Laura written authority to release the kit, and brief her on §5.1 | Larry |
| BCP-4 | Hold the first annual tabletop (§8) and record it | Larry + Laura |
| BCP-5 | Build and maintain an institutional customer contact list (business and security contacts) that Laura can reach without production access | Laura |
| BCP-6 | Confirm status.gevell.com is merged, monitored and documented as the customer status channel (deployed 2026-09-20 ahead of merge), and decide who can post to it | Larry |
| BCP-7 | Confirm the company mailboxes (larry@gevell.com, security@gevell.com, Laura’s address) are hosted independently of Resend and work if Resend is down | Larry |
| BCP-8 | Decide whether to buy cyber-liability insurance, and record the decision | Larry + Laura |
| BCP-9 | Complete the DR plan actions (restore test, PITR decision, independent backups) that the recovery targets here rely on | Larry |