The first line of a business continuity plan template for a small SaaS is a name: who decides, and who decides when that person cannot be reached. Seven more sections fit on the same page: what must keep running, how long each part can be down, what it depends on, how to restore it, who to tell, where the credentials live, and when it was last rehearsed.
The business continuity plan template: eight sections on one page
A business continuity plan template for a small SaaS has eight sections on one page: who decides and their deputy, what must keep running, how long each part can be down, what it depends on and who owns the account, how to restore it, who to tell, where the credentials live, and when it was last exercised.
The plan is one piece of the data consistency checklist for SaaS, the wider list for keeping a small app’s data correct and recoverable. Copy the table below into your company docs, keep the first two columns, and replace the example lines with your own.
| # | Section | What to write | Example line |
|---|---|---|---|
| 1 | Who decides | The incident lead and a deputy, with phone numbers that work when email does not | Lead: the CEO, personal mobile. Deputy: the CTO, personal mobile. Either one can declare an incident. |
| 2 | What must keep running | The product functions, ranked, taken from the impact analysis | Sign in and the core workflow first, then payments, then email, then the marketing site. |
| 3 | How long each can be down, and how much data it can lose | The targets the impact analysis produced, never guessed | Core workflow: the recovery time and data-loss targets from its row in the impact analysis. |
| 4 | What each part depends on, and which account owns it | Hosting, database, authentication, payments, email, DNS and the domain registrar, source control; the owning account for each | Database: managed Postgres on the company account, both founders as owners. |
| 5 | How to restore each part | A link to the runbook, not the steps | Database: link to the restore runbook and the date it was last followed. |
| 6 | Who to tell, and how | Customers, the status page, key vendors, and any contractual notice period some customers have | Status page first, then the drafted customer email; the one customer whose contract sets a notice period gets a direct message. |
| 7 | Where the credentials and recovery codes live | The vault, and who else can open it | Company password manager, both founders can open it; printed recovery codes kept by the deputy. |
| 8 | When it was last exercised | The date, what failed, and the next review date | Tabletop and timed restore on [date]; gaps found: [list]; next review: [date]. |
The example column turns the business continuity plan template into a sample you can read top to bottom before you write a word of your own. What should be included in a business continuity plan for a company whose whole operation is one hosted app comes down to those eight rows. A business continuity plan for natural disasters is mostly a premises plan, with evacuation routes and alternate sites; for a company with no premises that matter, I read that part as carried by the hosting provider, so this template leaves it out.
Keep the business continuity planning template to one page because the person reading it during an outage may not be the person who wrote it. Store it as a versioned page in the company’s docs, and keep a printed copy of sections 1, 6 and 7: my working rule, since the plan is needed exactly when the usual tools are down. Ready.gov’s own template asks for an electronic copy “stored on a secure and accessible website that would allow team member access if company servers are down.” There is no file to download here: the table copies into any docs tool and prints from the browser.
What is business continuity planning (BCP), and how is business continuity management different?
Business continuity planning, BCP, is writing down how the company keeps delivering its product through a disruption. NIST describes the plan as documented instructions or procedures for sustaining an organization’s mission and business processes during and after a significant disruption. Business continuity management is the ongoing program around that plan: an owner, reviews and exercises.
That wording follows NIST’s definition of a business continuity plan, which comes from NIST SP 800-34 Rev. 1. The same publication allows a plan to “address only the functions deemed to be priorities”, which is the permission a two-person company needs to keep the document short.
Management, for a company this size, is a calendar reminder and a named owner. The program that larger companies staff with a team shrinks to one person who opens the plan on a set date, runs the exercise and fixes what it finds.
For the BCP planning steps, Ready.gov’s business continuity planning page walks through six in its training videos: prepare, define the plan’s objectives, identify and prioritize risks and impacts, develop strategies, define teams and tasks, and test. A business continuity planning framework for a small SaaS is the eight-section plan plus the impact analysis behind it, not a certification program. Business resilience is the wider aim of absorbing a disruption and carrying on; continuity planning is the written and tested part of it.
A small SaaS needs a business continuity plan for a plain reason: someone asked for it, usually a customer’s security form, an investor or an insurer. The disruptions it prepares for are mundane ones: a founder who cannot be reached, a provider account that gets locked, a bad deploy with no way back, a domain that expired.
Business continuity and the disaster recovery plan: one document or two
A business continuity plan keeps the company operating: people, decisions, communication and suppliers. A disaster recovery plan restores the technology: backups, rebuild steps and failover. For a company whose whole operation is one hosted app the two overlap, so one document that links out to the recovery runbooks works if it answers both questions.
NIST SP 800-34 Rev. 1 treats them as separate plans in a longer list. Its business continuity plan “focuses on sustaining an organization’s mission/business processes during and after a disruption”, and its disaster recovery plan is “an information system-focused plan designed to restore operability of the target system, application, or computer facility infrastructure at an alternate site after an emergency.” NIST ties that disaster recovery plan to disruptions that need relocation; recovering a single system, wherever it runs, is a third type, the information system contingency plan. A hosted app has no building to leave, so most of a small SaaS’s recovery work is that third kind, whatever the document is called.
| Question | Business continuity plan | Disaster recovery plan |
|---|---|---|
| What it protects | The company’s operation: people, decisions, customers, suppliers | The systems and the data |
| Who opens it first | The incident lead or the deputy | Whoever runs the restore |
| What starts it | Any disruption to what customers pay for, including a founder who cannot be reached | A failed system, a lost account or damaged data |
| What it points to | The recovery runbooks and the customer message | The backups and the restore steps |
| Plan-type name in NIST SP 800-34 | Business Continuity Plan (BCP) | Disaster Recovery Plan (DRP) |
Only the plan-type names in the last row are NIST’s; the other cells are my reading of the split for a small SaaS. A combined disaster recovery and business continuity plan template is this page’s eight sections with section 5 linking to the recovery runbooks, and the recovery side, the timed drill and its evidence belong to a separate document, the disaster recovery checklist for SaaS. A disaster recovery policy template is the policy paragraph further down, whose third sentence already names the recovery targets. At a small company, business continuity and disaster recovery planning for IT professionals and founders is often one person’s job, which is why the people lines carry more weight than the number of documents.
How to write a business continuity plan: the impact analysis first, then systems, people and policy
Write the parts in this order: the impact analysis, the lines about systems, the lines about people, and the policy. The impact analysis goes first because it produces the numbers the other sections copy. Each part below also names the mistake it tends to invite.
The BIA template: a business impact analysis for a product with one database
A BIA template, a business impact analysis, is a table with one row per product function and the harm of losing it after an hour, a day and a week. It produces each function’s maximum tolerable downtime and, from that, the recovery targets the plan uses. Do it before the plan, because the plan’s numbers come from it.
Ready.gov’s business impact analysis guidance says a BIA “predicts the consequences of a disruption to your business, and gathers information needed to develop recovery strategies.” Among the effects it lists to weigh are lost sales and income, contractual penalties, and customer dissatisfaction or defection. NIST SP 800-34 splits the analysis into three steps: find the business processes and how critical their recovery is, identify the resources they need, and set recovery priorities. The column that anchors the table is maximum tolerable downtime in NIST’s glossary: “The amount of time mission/business process can be disrupted without causing significant harm to the organization’s mission.”
| Function | After an hour | After a day | After a week | Maximum tolerable downtime | Recovery time target | Recovery point target | Depends on |
|---|---|---|---|---|---|---|---|
| Sign in | No one can use the product | Support inbox fills, refund requests | Customers leave | [your answer] | [shorter than the downtime] | [data you can lose] | Auth provider, database, reset email |
| Core workflow | Customers cannot do the job they pay for | Refunds, missed commitments | Churn, contract breach where uptime is promised | [your answer] | [shorter than the downtime] | [data you can lose] | Host, database |
| Take payment | New sales stop | Failed renewals pile up | Lost revenue, involuntary churn | [your answer] | [shorter than the downtime] | [data you can lose] | Payment provider, webhooks |
| Send email | Password resets and receipts stop | Users locked out of reset flows | Trust damage | [your answer] | [shorter than the downtime] | Not applicable | Email provider, DNS |
| Admin and support | Staff work around it | Slower answers | Backlog | [your answer] | [shorter than the downtime] | [data you can lose] | Host, database |
| Marketing site | Few notice | Lost sign-ups | Lost sign-ups | [your answer] | [shorter than the downtime] | Not applicable | Host, DNS |
The rows are product functions, not servers, and the impact cells are my reading of what a small SaaS loses; the three time columns come from Ready.gov’s point that the timing and length of a disruption can change the loss. Set the recovery time target inside the maximum tolerable downtime: NIST says the recovery time objective “must normally be shorter than the MTD.” The recovery point target answers a separate question, how much data the function can afford to lose, and NIST keeps it outside the downtime figure. The live restore-drill guide covers what recovery time and recovery point objectives a small app should choose, so I do not repeat that here.
Those targets, per function, are the business continuity plan objectives. The BIA comes before the BCP because the plan’s recovery order is the BIA’s ranking, and Ready.gov says the processes “with the greatest operational and financial impacts should be restored first.” The risk assessment for a business continuity plan is the companion list of what could cause each outage, such as a provider incident, a locked account, a bad migration or a lapsed domain, and it supplies the scenario for the tabletop further down.
Where this part goes wrong: the same short target for every function, because it sounds responsible, and then a target the backups cannot meet. The honest input is how long the last restore actually took. Redo the BIA when pricing, contracts or architecture change: my working rule.
BCP in IT: the IT business continuity plan, and the lines that are about systems
BCP in IT, the IT business continuity plan, covers the systems, which for a software company is most of the plan: a dependency map with one row per provider the product needs, its account owner, and the workaround. Each row can fail three ways: the provider is down, the account is locked or lost, or the data is damaged.
An information technology business continuity plan at a larger company also covers offices, networks and laptops. At two people, the business continuity plan for IT systems is the map below, and business continuity planning for IT starts from it rather than from a list of servers.
| System | Provider role | Account owner | If it is gone | Workaround | Runbook |
|---|---|---|---|---|---|
| Hosting | Managed host | Company account; both founders as owners where allowed | Down: wait, update the status page. Locked: billing failure or a departed contractor’s login. Damaged: a bad deploy | Redeploy the last good build | Redeploy and rollback |
| Database | Managed Postgres | Company account; both founders | Down: wait. Locked: as above. Damaged: a bad migration or deleted rows | Restore to a new database, then repoint the app | Database restore |
| Authentication | Hosted auth provider | Company account; both founders | Down: no one signs in. Locked: users cannot reset. Damaged: user records lost | Status page message; restore user data with the database | Auth recovery |
| Payments | Payment provider | The founder’s account; a second Super Administrator | Down: checkout fails. Locked: payouts frozen. Damaged: webhooks missed | Replay missed events after recovery | Payment reconciliation |
| Transactional email provider | Company account; both founders | Down: resets and receipts stop. Locked: sending suspended | Queue messages; post the status on the status page | Email provider switch | |
| DNS and domain | Registrar and DNS host | The founder’s account; a second member | Down: the app is unreachable. Locked or expired: the domain lapses | Renew; auto-renew on, with a card that is not about to expire | Domain recovery |
| Source control | Git host | Company organization; two owners | Down: no deploys. Locked: code unreachable | Deploy from a local clone | Source access |
In a healthcare community app I audited, schema changes were applied with a push command straight against its one live database, with no recorded migration history and no reverse step. The managed host could roll back the front end, not the database. The lesson I take from it: a dependency row whose workaround is to roll back the deploy needs a second line for the data.
Who owns each provider account is its own control, covered in when a developer owns your hosting account. Database access and settings belong in how to harden managed database settings, and the restore steps go in runbooks, which have a format of their own: the runbook template. IT continuity management is IT service continuity management, a practice current ITIL calls service continuity management: the same idea, run as a standing process.
The usual gap in a first draft of this map is a list of servers the company does not operate, with no row for the domain registrar or for the email provider that sends password resets.
The people lines: what a two-person company cannot lose
A two-person company’s largest continuity risk is one of its two people. The plan needs a deputy who can reach every account with owner rights, recovery codes the deputy can find, a deploy the second person has actually run, and one outside contact who knows where the plan is kept.
The risk has a shape you can list: the only person who can deploy, the only holder of the registrar login, the only name on the payment account. The outside contact can be an advisor or a contractor; what matters is that someone outside the company knows the plan exists and where it lives.
Owner rights depend on the provider and the plan you pay for. Vercel’s Hobby plan lists no team collaboration features, and its docs put the owner role on the Pro and Enterprise plans. Vercel’s docs add: “For continuity, we recommend that at least two individuals have owner permissions.” GitHub recommends at least two owners per organization, since with one owner “the organization’s projects can become inaccessible if the owner is unreachable.” Stripe allows one account owner, so the deputy line there is a second Super Administrator, a role only an existing Super Administrator can assign. Supabase, Cloudflare and Resend each let an account add another member.
Where a plan allows no second member, the deputy line records the provider’s own recovery route instead, never a shared login. Saved recovery codes are one such route; Vercel’s docs say its codes “can be used to access your account if you lose access to your 2FA methods.”
A plan only its author can open fails this whole section.
The business continuity policy: one paragraph above the plan
A business continuity policy is the commitment above the plan, and five sentences cover it: purpose and coverage, the owner, that an impact analysis sets the recovery targets, that the plan is exercised and reviewed on a stated interval, and where the evidence is kept. A reviewer asks for the last exercise’s date.
[Company] keeps a business continuity plan so that its product stays available to customers, or returns within set targets, through a disruption to its people, providers or systems.
[Name, role] owns this policy and the plan beneath it.
Recovery targets for each product function come from a business impact analysis.
The plan is exercised and reviewed about once a year and after any major change to the product, its providers or its contracts.
Records of each exercise, the gaps it found and their fixes are kept in [location].Paste the block above the plan as a business continuity policy template; filled in, it is the business continuity policy sample a customer’s form can take as it is. The interval in the fourth sentence is my working rule, not a standard. A business continuity planning policy for a company this size needs nothing beyond these five sentences. The same five sentences serve when a form calls the document a business resilience policy.
In my reading, a questionnaire usually asks for the policy and the date of the last exercise; where those questions sit in the forms is a separate topic: security questionnaire examples. This policy is a working document, not legal advice, and it certifies nothing.
Promising a yearly exercise nobody runs is the trap in this part: the policy then records a commitment the company is already breaking.
A filled example: a business continuity plan sample for a two-person SaaS
A business continuity plan sample for a two-person software company fills the eight sections for one hosted app: two names, the product functions ranked with targets taken from the impact analysis, a provider row for each dependency with its account owner, links to the restore runbooks, a customer message drafted in advance, and the date of the last exercise.
The company is fictional, and every figure below is an assumption of the example, not a recommendation. It sells a scheduling product, runs on a managed host with a managed Postgres database, a hosted auth provider, a payment provider and a transactional email provider, has a few hundred paying customers, and has promised no customer an uptime figure. Provider names stay as roles because the example endorses none of them. It is a simple business continuity plan example on purpose: a two-person company keeps current only what it can read in one sitting.
The filled BIA comes first.
| Function | Maximum tolerable downtime | Recovery time target | Recovery point target |
|---|---|---|---|
| Sign in and core scheduling workflow | Four hours | Two hours | A day of data (daily backups) |
| Take payment | A day | Half a day | The payment provider’s own records (assumed) |
| Send email | A day | Half a day | Not applicable |
| Admin and support | Three days | A day | A day of data |
| Marketing site | A week | Three days | Not applicable |
Daily backups can lose up to a day of bookings. If that is not acceptable, the backups change, not the target. Then the eight sections, filled in.
| Section | Filled in |
|---|---|
| Who decides | Lead: the CEO. Deputy: the CTO. Both mobile numbers are on the printed copy. |
| What must keep running | Sign in and scheduling, then payments, then email, then admin and support, then the marketing site. |
| Targets | Copied from the filled BIA above, one line per function. |
| Dependencies | Managed host, managed Postgres, hosted auth, payment provider, email provider, registrar and DNS, Git host; each on a company account with both founders as owners where the provider allows it, otherwise the recovery route is written next to it. |
| Restore | Links to the redeploy, database restore, domain and email runbooks. |
| Who to tell | Status page first. Drafted email: Bookings are unavailable right now. We are restoring service and will post the next update by [time]. |
| Credentials | A shared vault in the company password manager that either founder opens; the deputy holds the printed recovery codes. |
| Last exercised | Tabletop and timed restore on [date]; restore took [measured time] against the two-hour target; gaps: [list]; next review: [date]. |
The durations are assumptions of the example: change them and the BCP sample becomes yours. At five people, this example plan grows into business continuity management: a named owner for reviews, a second deputy, and a real on-call rota. The first enterprise contract changes more, because a named uptime commitment turns the targets into obligations, and the BIA has to be redone against that contract.
Put this example next to the recovery runbook that section 5 links and you have a sample business continuity and disaster recovery plan in two documents. No PDF is attached: the business continuity plan example above lives on the page and prints cleanly from the browser.
How to verify the result: a one-hour tabletop and one real restore
A business continuity plan is verified in six steps: the deputy opens it unaided, the deputy signs in to every provider with the rights the plan assumes, a one-hour tabletop walks one scenario through every section, one restore is timed against the target, the customer message and status page are drafted, and the date, gaps and next review are recorded.
Each step can fail, and each leaves evidence to keep.
- 01 The deputy opens the plan from a phone without the author's help. Evidence: how long it took. Fail: they cannot find it.
- 02 The deputy signs in to every provider in the dependency map with the rights the plan assumes. Evidence: the dated list of sign-ins. Where a provider allows no second member, record its recovery route instead.
- 03 Hold a tabletop hour: pick one scenario from the risk list, such as the lead being on a flight while the database is corrupted, walk it through every section, and write down every question nobody could answer. Evidence: that list.
- 04 Run one real restore the way the restore-drill guide describes, time it, and write the time next to the target from the impact analysis. If the restore took longer, change the target or the backups, never the stopwatch. Evidence: the measured time beside the target.
- 05 Send the drafted customer message to an internal list, and draft an incident on the status page without publishing it, unless the tool offers a private test. Evidence: the draft.
- 06 Record the date, the gaps found and the next review in the last section of the plan. Evidence: that dated line.
On a free database plan there may be no managed backup to restore. Supabase’s backups page says it automatically backs up “all Pro, Team, and Enterprise Plan projects on a daily basis” and recommends that free-tier projects export their data with the Supabase CLI and keep off-site backups. If that is your situation, the missing backup is the plan’s first gap.
The status page itself is covered in a status page for a small SaaS. What to back up, and how long to keep it, is in the database backup checklist for startups.
Where the sprint fits
In the Production Hardening Sprint, the deliverables closest to this page are these, each in the published words. Deliverable 4.7: “Verify automated backups, set retention, and perform a real restore test.” Deliverable 4.12: “Restore the application and data into a fresh environment, time the recovery, and document the procedure”, and it is verified this way: “Record the timed drill, recovered services, integrity checks, and observed recovery limits.” Deliverable 13.3: “Document deployment, rollback, key rotation, backup restoration, and the response to each operational alert.” Deliverable 2.8: “Move every service the product depends on (database, hosting, payments, email, AI, domain) into an account the founder owns, with the founder as the owner role, billing in the founder’s name, and any previous builder removed.” Deliverable 8.7: “Provide a status page for service availability and incident communication.” Formal third-party certifications and independent audit opinions are separate from the sprint deliverables. Legal advice and certification are separate services. Each deliverable is listed in the published scope.
Common questions about business continuity plans
What are the 5 components of a business continuity plan?
PNC’s small-business guide names five: risk assessment, impact analysis, recovery strategies, training and continuous improvement. Frameworks vary by source, as the same page says, and its own FAQ gives a second, different list of five. For a small SaaS, the eight sections above cover all five: the impact analysis and its risk list, the dependency map and runbooks as recovery strategies, the tabletop as training, and the dated review line as continuous improvement.
Who prepares a business continuity plan?
The person accountable for the business prepares it with the person who runs the systems, which at two people means both founders. A consultant or an advisor can review the plan and point out gaps, but cannot own it: the owner is the one who will be called during the outage and who runs the exercise.
What makes a good business continuity plan?
A good one is short enough to keep current, takes its targets from an impact analysis rather than a guess, names a deputy for every account, and carries the date of an exercise whose gaps were fixed. A dated tabletop and a timed restore are the proof for that last point.
What is the standard format for a business continuity plan?
Public templates differ in length and purpose. Ready.gov’s business continuity plan template runs four pages, from program administration and the continuity team through the impact analysis, recovery strategies, manual workarounds, incident management, testing and plan maintenance. Two other public templates are FEMA’s continuity plan template for non-federal entities and FINRA’s small-firm template, which FINRA describes as an optional tool for small introducing firms. NIST SP 800-34 keeps sample contingency plan templates for information systems and a sample impact analysis template in its appendices. I would pick the shortest format you will actually keep current, which for a small SaaS is the one-page table at the top of this page.
Can you give me an example of a business continuity risk?
Four common ones for a small SaaS: the only person who can deploy is unreachable, a provider account is locked after a billing failure, the domain lapses because the renewal card expired, and a migration corrupts the database. Each one belongs in the risk list, and each makes a good tabletop scenario.
The checks in this guide show you where the app is open. The sprint below closes those gaps, tests the result and writes the evidence down.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase