Business Continuity Plan

Purpose

This Business Continuity Plan (BCP) sets out how Maelstrom AI aims to continue delivering its two platforms — Provii (zero-knowledge age verification) and downpipes (no-custody backup & disaster recovery for the Cloudflare data layer) — during significant disruptions, including infrastructure failures, cyber attacks, or other disasters.

Scope

This plan covers:

• Maelstrom AI platform services — Provii (provii-verifier, provii-issuer) and the vendor-operated downpipes surfaces (control-plane, update channel, release pipeline)
• Recoverability of Maelstrom’s own Cloudflare estate via our self-hosted production instance of downpipes
• Development and deployment capabilities
• Customer support and communication
• Team member availability and coordination

Out of Scope:

• End-user devices (customer responsibility)
• Relying party integrations (customer responsibility)
• Operation of the downpipes engine and console inside a customer’s Cloudflare account (customer-operated; complementary user-entity control)
• Physical offices (we’re fully remote)

Business Impact Analysis

Critical Services

Non-Critical Services

Disaster Scenarios

Scenario 1: Cloudflare Regional Outage

Likelihood: Low (Cloudflare has >300 PoPs globally)

Impact: Medium (automatic failover to other regions)

Response:

Prevention: Accept this risk (documented in Risk Register - beyond our control)

Scenario 2: Cloudflare Global Platform Outage

Likelihood: Very Rare (last major outage: 2020)

Impact: Severe (complete service unavailability)

Response:

Long-Term Mitigation (considered but not implemented):

• Multi-cloud deployment (AWS Lambda + Cloudflare Workers)
• Decision. Cost and complexity exceed benefit given Cloudflare’s reliability
• Reviewed. Annually during BCP review

Scenario 3: Provii Signing Key Compromise

Applies to: Provii credential-signing keys. (downpipes archives are sealed under customer-held keys that Maelstrom never holds; the vendor-side downpipes signing keys are addressed in Scenario 7.)

Likelihood: Low (strong controls in place)

Impact: Severe (trust model compromised)

Response: See Incident Response - Signing Key Compromise section

Summary:

Prevention: Keys stored in Cloudflare Workers secrets; HSM may be evaluated as key management requirements grow

Scenario 4: GitHub Outage or Account Compromise

Likelihood: Low for outage, Medium for account compromise attempts

Impact: High (cannot deploy, CI/CD blocked)

Response:

If GitHub is Down:

• Wait for restoration (no alternative deployment mechanism)
• Use local development environments
• Manual deployment possible via wrangler deploy (requires Cloudflare credentials)
• Communicate delay to stakeholders

If Account Compromised:

Prevention: MFA required, hardware security keys planned

Scenario 5: Loss of Key Personnel

Likelihood: Low but possible

Impact: Medium (knowledge loss, capability reduction)

Response:

Sudden Unavailability (illness, accident):

• Maelstrom AI operates with a single operator (ISMS Owner); there is an acknowledged single-operator bus factor
• Documentation enables continuity (this ISMS, code comments, README files, deployment runbooks)
• Access recovery procedures are documented, including account recovery paths for Cloudflare and GitHub
• Critical procedures documented (deployment, incident response, key rotation)

Planned Departure:

Mitigation:

• Public documentation of all processes (reduces knowledge silos)
• Infrastructure as code (no manual “tribal knowledge”)
• All critical access held by the ISMS Owner (sole operator); access recovery is addressed in this Business Continuity Plan
• Standard tools and practices (not bespoke systems)

Scenario 6: Supply Chain Attack

Likelihood: Medium (attacks on npm/crates.io have occurred)

Impact: Severe (compromised artefacts distributed)

Response: See SLSA Level 3 protections

If Attack Detected:

Prevention:

• Hermetic builds (tamper-proof)
• Artefact signing (detects tampering)
• Security scanning in CI/CD
• Dependency pinning (Cargo.lock, package-lock.json)

Scenario 7: downpipes Vendor-Side Signing Key Compromise

Applies to: the two vendor-side downpipes signing keys only — the Licence Signer (Cloudflare Secrets Store, control-plane) and the Update Signer (held offline by the operator, never deployed to any Worker). Customer archive-protecting keys are out of scope here: they are customer-held and Maelstrom never possesses them.

Likelihood: Low (Update Signer offline; Licence Signer in Secrets Store)

Impact: Medium — no loss of customer data confidentiality (these keys do not protect archive contents), but a compromised Update Signer could be used to attempt a malicious engine update, and a compromised Licence Signer could mint spurious licence tokens.

Response:

Prevention: Update Signer held offline (air-gapped from any Worker); Licence Signer isolated in Cloudflare Secrets Store; signature-pinned, pull-only update channel with canary-gated safe-apply and automatic rollback; control-plane fail-open so a vendor-side incident never gates customer backup or restore.

Recovery Procedures

Service Recovery

For provii-verifier or provii-issuer:

# Ensure you have latest code
git checkout main
git pull

# Navigate to service directory
cd provii-verifier  # or provii-issuer/worker

# Deploy with wrangler
wrangler deploy --env production

# Verify deployment
curl https://verify.provii.app/health  # or issuer endpoint

# Restore KV value example
wrangler kv:key put --binding=CONFIG \
  "config_key" "config_value" \
  --env production

Development Recovery

If development environment compromised:

Communication Plan

Internal Communication

Emergency Contact Method: ISMS Owner (sole operator) is the primary responder; contact via Signal or direct phone

Escalation Chain:

1. ISMS Owner (first responder, technical response, and major decisions)
2. Customer communication handled directly by the ISMS Owner

Communication Channels:

• Primary. Signal (encrypted, mobile)
• Secondary. Email (for non-urgent coordination)
• Tertiary. Direct phone calls (true emergencies)

Customer Communication

Status Communication:

• Primary. Status page (if implemented) or GitHub Pages
• Backup. Email to registered contacts
• Social Media. X/Twitter @proviiwallet for major outages

Communication Templates:

Subject: [Provii Status] Service Degradation - [Service Name]

We are currently experiencing degraded performance on [service name].

Impact: [description]
Estimated Resolution: [timeframe or "investigating"]
Updates: [frequency]

We will provide updates every [30min/1hr] until resolved.

For real time updates, follow @proviiwallet or check status.provii.app

We apologise for any inconvenience.

Subject: [Provii Status] Resolved - [Service Name]

The issue affecting [service name] has been resolved as of [time] UTC.

Impact Duration: [X hours/minutes]
Root Cause: [brief, non-technical explanation]
Prevention: [what we're doing to prevent recurrence]

All services are now operating normally. We apologise for the disruption.

A detailed post-mortem will be published within 5 business days.

Subject: [Provii Security Advisory] [Brief Description]

We are issuing this security advisory regarding [issue].

Impact: [who is affected]
Action Required: [what customers need to do]
Timeline: [by when]

Details: [technical but understandable explanation]

For questions, contact security@maelstrom.au

We take security seriously and apologise for any inconvenience.

Testing and Maintenance

BCP Testing

Annual Full Test (Q4 each year):

• Simulate major outage scenario
• Test communication procedures
• Verify recovery procedures work
• Update documentation based on findings

Quarterly Table-Top Exercises:

• Walk through scenarios with team
• No actual system changes
• Verify contact information current
• Practice decision-making

Ad-Hoc Testing:

• After real incidents (lessons learned)
• When significant infrastructure changes
• When new team members onboard

Continuous Backup Verification: Recoverability of Maelstrom’s own Cloudflare estate is proven on an ongoing basis by the dogfooded downpipes instance — hourly canary integrity flights and scheduled in-account restore drills, evidenced through the engine’s signed reports. See Cloudflare Backup Evidence.

Backup Procedures

What We Back Up:

Cloudflare Data Layer — Self-Hosted downpipes

Maelstrom’s entire Cloudflare estate is backed up by our own production instance of downpipes (we run downpipes as a customer of our own product). This is a current, fully-operational state.

• Coverage. Workers KV, D1, R2, Secrets Store, and 51 zone/account configuration surfaces
• Encryption. Post-quantum hybrid, sealed under operator-held keys (no-custody)
• 3-2-1 fan-out. Each source written to two or more independent, Maelstrom-controlled destinations
• Recoverability. Continuously proven by hourly canary integrity flights and scheduled in-account restore drills; the MIT offline reader restores from archive bytes plus the offline key alone, with no vendor and no network
• Objectives. RPO under 1 hour, RTO under 4 hours
• Evidence. Cloudflare Backup Evidence

What We Don’t Back Up:

• Ephemeral state (Durable Objects, challenges)
• Audit logs (retained 90 days, then discarded; critical security event logs are retained for up to 365 days)
• Analytics data (acceptable loss)

Maintenance Windows

Planned Maintenance: Rare (serverless architecture auto-scales)

If Maintenance Required:

1. Announce: 72 hours advance notice
2. Schedule: Off-peak hours (02:00-04:00 UTC)
3. Duration: Target < 30 minutes
4. Rollback: Prepared before starting
5. Communicate: Start, progress, completion

Recovery Time Objectives (RTO) / Recovery Point Objectives (RPO)

Continuous Improvement

After Every Incident:

• Review BCP effectiveness
• Update procedures based on lessons learned
• Test new procedures

Annual Review (Q1):

• Update contact information
• Review RTO/RPO targets
• Update disaster scenarios based on threat surface
• Validate backup and recovery procedures
• Test full plan with tabletop exercise

Next Scheduled Review: 2026-05-15

Related Documents

1. Incident Response Policy - Responding to security incidents
2. Risk Register - Business continuity risks
3. Information Security Policy - Overarching security principles
4. ISMS Scope Statement - Two-platform scope and the downpipes operating-model boundary
5. Cloudflare Backup Evidence - Self-hosted downpipes backup of Maelstrom’s Cloudflare estate

Document Information

• Version. 1.2
• Effective Date. 2025-01-13
• Last Updated. 2026-06-19
• Owner. ISMS Owner
• Maintained By. Security Lead
• Review Frequency. Annually, after major incidents
• Next Review. 2026-11-21
• Classification. Public
• Change (1.2). downpipes added as second in-scope platform; the legacy backup worker retired in favour of self-hosted downpipes. Made the BCP cross-cutting: added the downpipes vendor-side surfaces (fail-open control-plane, signature-pinned pull-only update channel, offline-held Update Signer) to the BIA, RTO/RPO table and a new vendor-side key-compromise scenario; reframed the Cloudflare data-layer backup and recovery onto Maelstrom’s own production instance of downpipes (3-2-1 fan-out, post-quantum sealing under operator-held keys, hourly canary flights and restore drills, MIT offline reader); recorded the no-custody operating-model boundary (engine/console continuity is a customer CUEC).