Disaster Recovery & Business Continuity Plan

This plan covers the production Kavanah service — the web application, the REST API, the scheduled background jobs, and the production Postgres database that holds customer workspace data. Its objective is to restore service after a disruptive event with a bounded amount of data loss (the recovery point objective) and a bounded outage (the recovery time objective).

Out of scope: the customer-operated third-party systems Kavanah integrates with — Google Workspace, Microsoft 365, Jira, Monday, Notion, ClickUp and the rest. Those are recovered by their own operators under their own plans; Kavanah's responsibility is to degrade cleanly while a provider is unavailable and to re-establish and resync the connection when it returns. The full vendor inventory is on the Sub-processors page.

The following are Kavanah's targetrecovery objectives. They are engineering targets that the architecture and backup design are built to meet — not guarantees, and not a substitute for the commitments in an executed agreement.

The RTO clock starts when a disaster is declared (see B6), not when the first symptom appears. Support response targets during an incident are separate from these recovery targets and are stated by severity in the SLA.

Customer data lives in a managed Postgres database. The operational runbook requires all four of the following controls, and requires that they are verified quarterly— managed providers occasionally reset defaults during plan changes, so “we turned it on once” is not a control.

In addition, an ad-hoc manual snapshot is taken before any deliberately risky change — a destructive migration, a schema rewrite, or a large data backfill — so that the recovery path for a planned change is never the same as the recovery path for an unplanned one.

Restoring is not a switch that gets flipped. Kavanah's documented restore path always restores to a new database instance or provider branch, never in place over a live database. That ordering is deliberate: the damaged state stays available for forensics, and a restore that turns out to be non-viable does not compound the incident.

The restored database is then smoke-tested by running the application against it before any traffic is cut over. The documented smoke path is:

• The dashboard loads.
• Projects render.
• Clients render.
• A task can be created, edited, and deleted.
• Audit logs show recent rows.
• A user can log out and log back in.

If any step fails, the backup is not viable and the incident is escalated rather than closed. Restored copies are torn down once the restore is accepted or the drill is recorded — leaving them running accumulates cost and drifts from production state.

Backup configuration is a claim; a completed restore is evidence. Kavanah exercises the restore path on a recurring quarterly cadence against a real backup, on the principle that a backup that has never been restored is not a backup.

Each drill is recorded in a drill log with:

• the date of the drill and who performed it;
• the age of the snapshot restored, which is the empirical check on the RPO target;
• the restore duration, which is the empirical check on the RTO target;
• the result — pass or fail against the smoke path in A4; and
• notes, including any anomaly observed even where the drill passed.

A drill is not complete until that row exists. The drill log is one of the artifacts available to enterprise customers under NDA, so a reviewer can check that the cadence has actually been kept rather than take the cadence on faith.

The scenarios below are the ones the plan is written against. Each has a documented response and the recovery objective it is measured against.

A meaningful part of Kavanah's recovery posture is the work that does not have to be done, because the architecture removes the failure mode rather than planning around it.

• Serverless, auto-scaling compute. There is no long-lived application host to rebuild. Compute runs on isolated per-request function instances; an instance failure is absorbed automatically, and recovering the application tier means promoting a build from version control rather than restoring a server.
• Managed database with provider-level redundancy. Replication, WAL archiving, and off-region copies are operated by a provider whose data centers are SOC 2-audited, rather than by scripts Kavanah maintains.
• No customer-operated infrastructure. Kavanah is delivered as a multi-tenant SaaS and operates no physical servers, so no facility, hardware, or network recovery is in scope on either side. There is nothing for the customer to restore.

The component inventory and trust boundaries behind this are documented on the Architecture Overview and, at specification level, in the Technical Data Sheet.

Part A answers “what happens when the infrastructure breaks.” Part B answers the question a buyer is usually really asking: “what happens to my data, and to my ability to keep working, if something happens to the company?” That covers key-person dependency, provider concentration, funding continuity, the survivability of the source code and configuration, and — the control that matters most — the customer's ability to get their data out without needing Kavanah's cooperation.

Kavanah is an early-stage company. A vendor at this stage that claims to have engineered away key-person risk, vendor concentration, and funding risk is not being straight with a reviewer. We would rather name the risks and point at the controls that make them survivable.

Key-person dependency

Kavanah is built and operated by a small engineering team, so key-person dependency is real. The mitigation is that operational knowledge is written down rather than held in one person's head: the database schema, its migrations, the infrastructure and scheduled-job configuration, and the operational runbooks — including the backup and restore procedure summarized in Part A — live in the same version-controlled repository as the application, and are exercised on the quarterly drill by whoever is on call rather than by a designated individual. That reduces key-person risk; it does not eliminate it, and we do not claim it does. The controls that actually protect a customer against it are B3 and B4.

Provider concentration

Kavanah depends on a small number of infrastructure providers — Vercel for compute, Neon for Postgres. The concentration is deliberate: fewer vendors means a smaller attack surface, a shorter sub-processor list, and fewer places customer data can sit. It is still a concentration, and it is mitigated by portability rather than by redundancy theatre. The database is standard Postgres with no proprietary data model that would prevent it being restored elsewhere; schema and migrations are defined in the repository; and the geo-redundant backup copies are ordinary Postgres artifacts that can be restored to a different provider. Every vendor that processes customer data is published on the Sub-processors page, and customers are notified of material changes to that list.

Funding continuity

A customer should not have to assume that a company of this stage will exist indefinitely, and no assurance we could write on this page would responsibly change that. So instead of asserting stability, the plan makes the failure survivable: continuous, self-service data portability (B4) plus negotiable escrow or transition terms mean that a customer's ability to keep operating does not depend on Kavanah's balance sheet. Current financial standing and funding position can be discussed with enterprise customers under NDA during procurement.

Everything required to rebuild and run the service exists as version-controlled source, not as the accumulated state of a running system:

• Source control.All application source is held in version control with full history, and every change is attributable to a reviewed commit — the same peer-review-before-merge control described in the Security Overview.
• Schema and migrations. The database schema and every migration are defined in the repository, registered in a single central place, and required to be idempotent — continuous integration applies them twice on every change to prove it. A database can therefore be rebuilt from source on new infrastructure rather than reverse-engineered from a running instance.
• Infrastructure and job configuration. Deployment configuration and the schedule of every background job are declared in the repository alongside the application, and a cron-health registry alerts when a scheduled job goes missing or starts failing.
• Secrets.API keys and signing secrets are held as environment secrets in the platform vault and never in source control. Recovery is documented: each is a provider-issued credential that an authorized owner can regenerate from that provider's console, so losing the vault does not mean losing the ability to stand the service back up.

This is the continuity control that matters most to a buyer, because it is the only one that does not depend on Kavanah being available to honour it. A customer who can export their data at any time is not exposed to our continuity risk in the way a customer who has to ask would be.

• Documented REST API.The workspace's operational data — projects, tasks, clients, time entries, discussions, and the rest — is readable through a documented, versioned REST API using a workspace API key, at any time, with no request to Kavanah required. The key inherits the issuing user's permissions, so an export is bounded by the same access control as the UI.
• Data-subject export and erasure. GDPR and CCPA data-subject requests — export or erasure of an individual's data — are supported in-product and can be initiated by a workspace owner from Settings → Data Governance.
• Escrow and extended transition. Where a procurement process requires more than self-service export, an escrow or extended-transition arrangement can be negotiated as part of an enterprise agreement — for example, source-code or data escrow with a third-party agent, a defined post-termination period during which the workspace remains readable for export, or a full database extract delivered on exit. These are negotiated terms, not default entitlements; ask for them during contracting.
• Retention on exit. Absent a negotiated term, post-termination retention and deletion follow the periods stated in your agreement and the DPA, so an exit is never a race against an immediate purge.

Customers are notified by email at the workspace owner and any security or operations contacts on record; enterprise customers with a named account contact are notified directly. For an availability incident, that means an initial notification, periodic updates while the incident is open, and a post-incident summary available on request for anything at S1.

Security incidents affecting customer data are notified in line with the Data Processing Addendum — without undue delay after Kavanah becomes aware, and carrying the information the DPA requires: the nature of the incident, the categories and approximate volume of data involved, the likely consequences, and the measures taken or proposed. That content exists so a customer acting as controller can meet their own regulatory deadlines without a second round-trip to us.

Severity definitions and first-response targets are the ones in the SLA — S1 Critical (production down or a security incident affecting availability or data) through S4 Low — and are used consistently across the SLA, this plan, and the incident-response process described in the Security Overview.

Stated in general terms, because the specifics are personnel details that belong in the internal runbook rather than on a public page:

• One accountable decision-maker. An incident has a single named owner from the moment it is opened — the on-call engineer by default — escalated to company leadership for anything carrying legal, contractual, or customer-notification consequences.
• Explicit roles. Technical recovery, customer communication, and the decision to declare a disaster are held explicitly and separately, so no step waits on an unassigned owner while the clock runs.
• Declaring a disaster is a low bar on purpose. Declaration is what starts the RTO clock and authorizes a restore. It is cheaper to declare and stand down than to spend the first hour debating whether the situation qualifies.
• Out-of-band communication. If the primary channel is part of what is broken, the team falls back to a channel that does not depend on Kavanah or on the affected provider.

• Review cadence.This plan is reviewed at least annually, and additionally after any material incident. A material incident updates the plan and the runbook — not only the incident ticket.
• The recurring test. The quarterly restore drill in A5 is the test of this plan. It is an execution test against real backup data rather than a tabletop exercise, and it produces the two measurements (snapshot age, restore duration) that the RPO and RTO targets are checked against.
• Configuration verification. The four backup controls in A3 are re-verified quarterly, because a correct configuration is not a permanent condition.
• Ownership. The on-call engineer owns the next drill, and the drill is not complete until its log row exists.

• Security Overview — encryption, access control, tenant isolation, incident response, and the compliance program.
• Service Level Agreement — the uptime target, severity ladder, and support response targets referenced above.
• Data Processing Addendum — processing terms, breach-notification obligations, and international-transfer safeguards.
• Sub-processors — every vendor that processes customer data.
• Architecture Overview and the Technical Data Sheet — the system design the recovery model rests on.
• Trust & Compliance — request forms for the artifacts shared under NDA.