Business Continuity Plan

Document owner: James Harcourt, Co-founder
Approved by: Max Taylor, Co-founder
Version: 1.0
Date: 2026-02-10
Next review: 2026-08-10
Classification / Scope: Internal
Applies to: Novatura staff/contractors who build/deploy/maintain client applications.

This BCP should be stored in:

1. an internal docs repo
2. 1Password/Sharepoint as PDF
3. offline copy on Incident Lead’s laptop

Purpose

This plan defines how we, as a company, maintain the continuity of our services and ensure we can recover our capabilities to deliver and support client work following disruptions. Examples of disruption:

• Device loss
• SaaS outage
• Credential compromise
• Data loss
• Supplier outage

Scope

In scope

• Corporate identity, access management, and productivity tools (e.g. email, IdP, password managers)
• Source code repositories and CI/CD pipelines used for service delivery (e.g. GitHub)
• Infrastructure owned and managed by Novatura (e.g. Cloudflare, VPS)
• Infrastructure access held or operated by the company on behalf of clients (e.g. AWS accounts, deployment credentials)
• Client support, incident response, and service communications.

Out of scope

• Client runtime infrastructure, platforms, and data for which the company has no contractual responsibility to manage, secure, or back up

Objectives (targets)

We outline recovery targets for our delivery capability:

RTO (Recovery Time Objective)

Company wide target to restore ability to develop/deploy/maintain systems as normal (outer bound): 24 hours.

Company wide target for restoring minimum viable service (inner bound): 4 hours.

A minimum viable service includes the ability to communicate with clients, access credentials, access repositories, deploy emergency fixes and restore systems from backups. Feature work, non-urgent maintenance and internal administration and project management tasks may be paused during disruptions until business as usual can be achieved.

RPO (Recovery Point Objective)

Asset	RPO	Notes
Source code repositories	4 hours	GitHub availability, with local copies
CI/CD configurations	4 hours	GitHub availability, with local copies
Corporate identity & productivity data	24 hours	SaaS provider availability and administrative recovery
Password manager	24 hours	Dependent on 1Password daily backups
Company‑managed VPS infrastructure	24 hours	Daily backups and/or snapshots
Company‑managed databases	24 hours	Backup frequency dependent
Client infrastructure managed by contract	Defined per SOW	Documented per client engagement
Client infrastructure not managed by company	N/A	Out of scope

Note: targets may be refined per client contract. TODO: how do we track these refinements?

Business Impact Analysis

Business activity	Impact if down	Max tolerable outage	Dependencies
Respond to support requests	High	4 hours	MS365/Email, WhatsApp
Deploy critical fixes	High	4 hours	GitHub, Forge, VPS, secrets, access to client env
Routine feature work	Medium	24–72 hours	GitHub, local dev env
Internal planning/admin	Low	72+ hours	MS365, Jira

Roles and responsibilities

Role	Name	Responsibility	Backup
Incident Lead	Niall Morrison	Owns coordination and client comms	Max Taylor
DevOps Lead	John Baker	Recovery actions for GitHub, CI/CD, secrets and deployments	Niall Morrison
Operations/Account Lead	James Harcourt	Client updates, prioritisation	Max Taylor
Approver	Max Taylor	Approves high-risk actions (credential rotation, access revocation)	Niall Morrison

Critical services & dependencies

Service / Asset	Purpose	Owner	Backup/Recovery approach	RTO	RPO
GitHub org, repos, CI/CD	Source control, PRs	James Harcourt	SaaS availability, distributed local clones	4 hrs	4 hrs
1Password	Secrets and credentials	Max Taylor	Built-in admin recovery, offline recovery credentials	4 hrs	4 hrs
Email/Calendar/MS365	Internal comms	John Baker	Microsoft DR, admin access recovery, alternate comms (WhatsApp)	4 hrs	24 hrs
Cloudflare	Web infrastructure, website deployments	Niall Morrison	SaaS availability, config-as-code where possible, documented manual rebuilds	4 hrs	24 hrs
Tailscale	Zero-trust network access	John Baker	SaaS availability, re-enrol devices, identify provider recovery	4 hrs	24 hrs
Laravel Forge	Server and deployment orchestration	John Baker	SaaS availability, servers can be re-attached/re-deployed	8 hrs	24 hrs
Expo	Toolchain and build orchestration	Niall Morrison	SaaS availability	8 hrs	24 hrs
VPS Infrastructure (Hetzner, Digital Ocean, Vultr, Fly.io)	Application hosting	John Baker	Provider snapshots/backups availability	8 hrs	24 hrs
S3 Storage (Backblaze)	Backups and file storage	John Baker	S3 versioning, retention policies, restricted IAM; restore tested periodically	8 hrs	24 hrs
Design/collaboration tools (Figma, Excalidraw, Jira)	Design and planning	James Harcourt	SaaS availability, exports where available	4 hrs	24 hrs

Backups and retention

Asset	Primary	Additional	Backup Schedule	Who can restore?	Retention Duration	Notes
Source code	GitHub	Distributed local copies	N/A	Anyone in org	N/A
Database backups	Backblaze (S3)		Daily	Incident Lead & DevOps Lead	14 days	Backups stored in object storage are protected using versioning, retention, and access controls rather than secondary backup systems.
Secrets	1Password		N/A	Anyone with admin recovery credentials	N/A	See Password Manager Recovery

TODO: We are exploring ways to improve S3 backups to align more closely with ISO27001, e.g. immutable backups, encrypted backups, local storage solutions and bucket hardening. In addition to this, we need to plan and schedule a restore testing cadence of a random client DB.

Password Manager Recovery

The company uses 1Password with four designated account organisers.

Member accounts can be recovered by an organiser using 1Password’s built‑in recovery process.

Organiser accounts are protected using individual recovery codes. Recovery codes are stored offline in printed form and retained securely. At least one copy is stored separately from day‑to‑day devices.

Loss of access by all organisers would require use of stored recovery codes. Use of recovery material is logged by 1Password.

Communication plan

For internal comms, our primary channel is MS Teams. Our fallback is the internal Novatura WhatsApp group that we use for informal comms, which can be used during MS outages.

During disruptions, status updates should be provided to customers by the Incident Lead and Account Lead with initial notice provided within 4 hours, and then daily until resolved. Use emails as the primary channel, and mobile as a fallback if available.

First Notification of Outage Email

Dear <CUSTOMER>,

We're writing to let you know about <ONE LINE OUTAGE SUMMARY>.

**What's happening?**
<BRIEF EXPLANATION OF IMPACT>

**What are we doing about it?**
<OUTLINE PLAN FOR REMEDIATION>

We'll keep you updated as the situation progresses.

Thank you for your patience and understanding while we deal with this.

Kind regards,

Post-Outage Summary Email

Dear <CUSTOMER>,

**What happened?**
There was an unexpected outage of the <APP> between <TIMESTAMPS> on <DATE>.

<BRIEF EXPLANATION OF IMPACT>

<BRIEF NON-TECHNICAL EXPLANATION OF CAUSE IF KNOWN>

**What did we do?**

<OUTLINE STEPS TAKEN TO REMEDIATE>

The outage was resolved at <TIMESTAMP> on <DATE>. <DESCRIBE CURRENT SYSTEM STATUS>.

**What are we going to do about it?**
<OUTLINE PLAN FOR CONTINUITY AND FAULT TOLERANCE>

Thank you for your patience and understanding while we dealt with this.

Kind regards,

Trigger events

Use these steps in the following scenarios:

• Loss/theft of a staff laptop used for client work
• Suspected compromise of GitHub/CI/password manager/cloud credentials
• Major SaaS outage (GitHub, MS365, Cloudflare) preventing delivery or support
• Accidental deletion or corruption of repo/secrets
• Loss of key personnel (sickness) affecting delivery service

Staff device lost or stolen (phone or laptop)

1. Revoke device Office365 sessions using this guide

2. Unlink sessions in 1Password via this page

3. Remove device from Tailscale via the console

4. Revoke device GitHub session using this guide

5. Revoke device Cloudflare session via this guide

6. Revoke device Forge session via the profile security settings

7. Revoke device Expo session via the console

8. Reset any credentials and rotate tokens as required.

9. Confirm disk encryption status and exposure risk. Wipe device via this guide

10. Issue replacement device and try to restore device data from iCloud.

11. Notify client if risk to client data/credentials is plausible.

12. Create an incident summary in Sharepoint under Documents/Cybersecurity & Compliance/Incidents.

GitHub compromise suspected

1. Freeze: remove org access for suspected accounts. Get someone else to review audit logs during account recovery.

2. Change password on the primary email address using a non-compromised device (revoke Office365 sessions if necessary).

3. Attempt the account recovery flow

4. If this doesn’t work: Open a ticket with GitHub Support from an email you control. Include: your username, primary email(s), approximate account creation date, names of private/public repos, any invoices or payment IDs, and a short timeline of what happened. Mention that the account has been compromised.

5. Once you regain access:

6. Immediately rotate GitHub password and set up 2FA again.

7. Revoke active GitHub sessions using this guide

8. Revoke unknown SSH keys, Personal Access Tokens, unauthorised OAuth apps.

9. Disable/rotate GitHub Actions secrets, deploy keys, environment secrets.

10. Check for newly added Actions workflows and edited branch protection rules.

11. Check repo access and organisation memberships for changes. Check latest commits and deployments. Re-deploy known-good versions if necessary.

12. Create an incident summary in Sharepoint under Documents/Cybersecurity & Compliance/Incidents.

Client Environment Credentials Compromised

1. Notify client immediately

2. Rotate/revoke keys/roles (client may do this while we support).

3. Audit deployment and build logs.

4. Confirm no malicious build artifacts.

5. Preserve evidence (logs) before redeploy if possible.

6. Redeploy from known-good commit.

7. Agree on notification obligations (client vs us), especially if personal data may be involved.”

SaaS Outage (GitHub, Office365, Cloudflare)

1. Switch to fallback comms channels if necessary.

2. Pause automated deployments if possible.

3. Alert affected clients to inform them of the outage.

4. Continue local work where possible.

5. Resume normal operations when service is restored. Frequently check status pages for progress.

Suspected data breach

Follow the steps in this playbook in event of data being not only lost, but stolen or exposed.

Testing and maintenance

A tabletop business continuity exercise is scheduled for 2026-08-10.

A review of this document is scheduled for 2026-08-10.

Related Playbooks

Information Security Policy

Read the policy document here.

Incident Playbook

In case of a security incident, follow this guide