Business Continuity SOP Template

Purpose & Scope

This section states why the SOP exists and exactly what it covers, so nobody has to guess during an actual disruption. Start with the trigger definition: name the specific conditions that count as an activation-worthy disruption for your business, for example an infrastructure or SaaS outage lasting longer than 30 minutes, loss of access to your primary workspace or office, a critical vendor or subcontractor going dark, a confirmed security incident, a key-person unavailability such as sudden illness or resignation, a regional emergency like a natural disaster, or a payment-processor or banking outage that blocks revenue collection. Vague triggers produce vague responses; specific triggers produce specific, rehearsed action. Next, define scope. Most agencies, consultancies, and small teams write one consolidated SOP that covers people, delivery tools, client-facing systems, and vendor dependencies together, because a single owner, often the founder or ops lead, is responsible for all of it. Larger organizations more often split this into three linked documents: an IT/infrastructure disaster recovery plan, a physical facilities plan, and a client/stakeholder communications plan, with this SOP acting as the coordinating document that references the others. Either approach works, but the scope needs to be written down so a reader knows immediately whether a given incident, say a laptop theft versus a five-day office closure, falls inside or outside this document. Explicitly state what is out of scope, and where the reader should go instead: for example, 'cybersecurity incident response is covered in our Incident Response Plan, not here' or 'IT infrastructure recovery time objectives live in our Disaster Recovery Plan; this SOP references but does not duplicate them.' Finally, name the document owner, the person accountable for keeping it current and for the authority to formally declare an activation, the date it was last approved, and the date of the next scheduled review. A reader should be able to answer three questions from this section alone: what counts as a covered disruption, who is accountable for this document, and where its boundaries sit relative to any other continuity or recovery documentation the organization maintains. It also helps to state, in one sentence, what success looks like for this SOP: not that nothing ever goes wrong, but that when something does, the team recognizes it, activates the right people, and keeps the promises it made to clients with as little visible disruption as possible. That single success sentence is worth revisiting at every review, because it keeps the rest of the document anchored to a practical outcome instead of becoming a compliance exercise nobody actually expects to use.

Roles & Responsibilities (RACI)

Every business continuity SOP fails at the moment of use if two people both think someone else is in charge, or if the one person who knows what to do is unreachable. This section fixes that with a simple RACI structure: who is Responsible for doing the work, who is Accountable for the outcome, who must be Consulted before a decision, and who is simply kept Informed. At minimum, name these roles, and critically, a named backup for each one: a Continuity Lead, accountable for declaring an activation and coordinating the response, often the founder, COO, or head of operations; a Communications Lead, responsible for all internal and client-facing notifications; an IT/Systems Lead, responsible for restoring access to tools, data, and infrastructure; a Client Delivery Lead, responsible for triaging active client work and deciding what pauses, what continues, and what gets reassigned; and a Vendor/Finance Lead, responsible for contacting critical vendors, payment processors, and, if needed, insurance. For each role, list a named primary and a named backup with direct contact information, a personal phone number, not just a work email that may be inaccessible, because the most common activation failure is a plan that assumes the one person who wrote it is always available. If your team is small enough that one person holds two or three of these roles, say so explicitly rather than leaving a gap; a solo founder or a two-person leadership team can still write 'Founder = Continuity Lead + Communications Lead; Ops Manager = backup for both' and that is a complete, valid answer. Add a short paragraph on decision authority: who can authorize emergency spending, for example an expedited vendor contract or emergency equipment purchase, up to what dollar amount without further approval, and what happens above that threshold. Ambiguity about spending authority during a live incident wastes exactly the time this SOP is meant to save. Close this section with an explicit escalation rule: if the Continuity Lead is unreachable within a defined window, commonly 15 to 30 minutes, the named backup automatically assumes authority. Write that rule down here; do not leave it implied, because an implied rule is not one your team can actually act on under pressure. Finally, list every role holder's out-of-office scenarios, planned vacations, parental leave, or a known busy season, so the backup assignment is never a surprise on the day it's actually needed; a rotating on-call calendar, even a simple shared one, closes this gap for teams whose leadership travels often.

Business Impact Analysis Summary

A business impact analysis, or BIA, is the exercise that decides which functions actually deserve rapid recovery, and this section is where you record the conclusions so the rest of the SOP can act on them without re-litigating priorities mid-incident. For each critical business function, client delivery, invoicing and payment collection, new-business or sales activity, internal communications, payroll, and any product- or platform-specific function you run, record three numbers: the Recovery Time Objective (RTO), the maximum acceptable time the function can be down before real damage occurs; the Recovery Point Objective (RPO), the maximum acceptable amount of data or work you can afford to lose or redo; and a plain-language impact statement describing what actually breaks if the RTO is exceeded, a missed client deadline, an unpaid invoice, a broken SLA, reputational damage. Rank functions from most to least time-critical. In practice, most agencies find that client-facing delivery and payment collection carry the tightest RTOs, often under 24 hours, while internal reporting or long-term planning work can tolerate several days of disruption without material harm. Writing this ranking down before an incident prevents the natural instinct to treat every task as equally urgent once something actually breaks, which is how teams burn their first, most valuable hours on the wrong problem. Include a short dependency note under each function: what tools, vendors, or people does this function rely on to operate at all? A project delivery function that depends entirely on one cloud-based project management tool has a different recovery path than one that also has an offline fallback, even something as simple as a shared spreadsheet and a phone tree. If you have never formally run a BIA, this section can start as a best-effort estimate from the Continuity Lead and department heads; agencies rarely need a formal, multi-week BIA exercise before this document becomes useful. Revisit and tighten these numbers at each review cycle described in the Testing & Review section below, and immediately after any real activation, since a live incident is the most accurate BIA data you will ever get. It also helps to note the financial exposure behind each RTO in rough terms, for example the approximate daily revenue at risk if invoicing is down, or the approximate cost of a missed contractual deadline, because a number attached to a delay makes the priority ranking self-evident to anyone reading the plan for the first time, including a new hire who joins the response team after the document was written.

Critical Systems, Vendors & Dependencies

List every system, tool, and third-party vendor your critical functions from the section above actually depend on, then note, for each one, what happens to your operations if it goes down and who your fallback contact is. This is the section generic continuity templates most often skip entirely, and it is usually the difference between a plan that works and one that only sounds good on paper. For each critical system or vendor, capture the system or vendor name and what it's used for, an internal owner who knows how to work around it or holds the account, a support and escalation contact, a named account manager or a support-tier phone number rather than a generic support email, your service-level expectation from them, do they publish an SLA and what does it promise, and a fallback, however imperfect, for operating without them for a defined period. Typical entries for an agency or consultancy include the primary project management or client portal platform, cloud file storage, email and calendar, video conferencing, the payment processor and invoicing tool, the domain registrar and hosting provider if you run client-facing sites, your accounting software, and any e-signature tool used for contracts. For SaaS and product teams, add the cloud infrastructure provider, the CI/CD pipeline, the customer support platform, and any third-party APIs the product itself depends on to function for end users. Flag single points of failure explicitly, a vendor, tool, or person with no fallback at all, because identifying these is the single highest-value output of this section. A payment processor with no backup means a processor outage stops all revenue collection; a project tool with no offline fallback means a tool outage stops all client-visible progress. You do not need to eliminate every single point of failure before this SOP is useful, but you do need to know where they are so the Continuity Lead isn't discovering them for the first time during an actual outage. Review and update this list at least twice a year and any time you add, switch, or drop a vendor or core tool; an out-of-date vendor list is one of the most common reasons a continuity plan fails silently.

Step-by-Step Activation & Escalation Procedure

This is the section most business continuity templates leave vague, describing what a good response looks like in general terms without ever writing down the literal sequence of actions a specific person takes in the first hour. That gap is exactly what this SOP closes: a numbered, minute-by-minute activation checklist your Continuity Lead, or whoever is on duty, can follow without having to think, because thinking clearly is the hardest thing to do in the first minutes of a real disruption. Step 1, Detect and Confirm, target within 15 minutes of the first signal: whoever first notices a potential disruption, a system outage alert, a vendor's status page, a call from a client, an inaccessible office, reports it immediately to the Continuity Lead and backup using the contact method defined in the Communications section. The Continuity Lead confirms whether the event meets one of the activation triggers defined in Purpose & Scope; if uncertain, they escalate on the assumption it does rather than wait for perfect certainty. Step 2, Declare and Assign Tiers, within 30 minutes: the Continuity Lead formally declares an activation and assigns a severity tier. Tier 1 is minor, contained to one function or tool, resolved same-day, internal notification only. Tier 2 is moderate, affects client-facing delivery or revenue collection, requires client communication, target resolution under 24 hours. Tier 3 is major, affects the whole team's ability to work, an office- or region-wide event, or a security incident, requiring full team activation and, likely, client-wide communication. The tier determines who gets activated next and how the Communications Lead frames outbound messaging. Step 3, Activate the Response Team, within 45 minutes: the Continuity Lead notifies the Communications Lead, IT/Systems Lead, Client Delivery Lead, and Vendor/Finance Lead per the tier assigned, using the pre-approved notification templates in the Communications section rather than drafting messages from scratch. If the Continuity Lead is unreachable within the 15 to 30 minute window set in Roles & Responsibilities, the named backup automatically assumes authority and proceeds from Step 2. Step 4, Execute Recovery Actions, ongoing, tracked against each function's RTO from the BIA: each Lead works their assigned recovery procedure and reports status to the Continuity Lead at a fixed cadence, every 30 minutes for Tier 3, every two hours for Tier 2, once at resolution for Tier 1. Step 5, Stand Down and Debrief, within 48 hours of resolution: the Continuity Lead formally declares the incident closed, the Communications Lead sends a resolution notice to anyone who received an activation notice, and the team runs a short after-action review covering what triggered it, what worked, what didn't, and what changes this SOP needs, feeding directly into the Plan Maintenance section. Print or save this five-step sequence somewhere it can be found in under a minute, a pinned document, a laminated card, or the top of this SOP itself, because the value of a rehearsed procedure disappears the moment someone has to go searching for it while the clock on Step 1 is already running.

Communication & Notification Protocols

An activation plan is only as fast as the message that starts it, so this section pre-writes the notifications themselves rather than leaving them to be composed under pressure. At minimum, prepare four message templates in advance: an internal team alert stating that the SOP is being activated at a given tier, the cause, who is coordinating, and when the next update will arrive; a client-facing notice for Tier 2 and Tier 3 events describing the disruption in plain, non-alarming language and whether active work is unaffected, paused, or being handled by a backup process; a vendor or partner request naming the specific ask and a point of contact; and an all-clear or resolution message for both internal and client audiences. Define the primary and backup channel for each audience. If your primary internal channel, whether that's a chat tool, a project platform's messaging, or email, is itself down, which is common during infrastructure outages, name a backup: a phone tree, a group SMS thread, or a shared, low-tech document everyone knows to check. The same logic applies to client communications: if your usual channel is a client portal and the portal is the thing that's down, you need a fallback, direct email or phone, already agreed on in advance. Assign who is authorized to speak externally. During a real incident, well-meaning team members sometimes post updates to clients or on social media before leadership has confirmed the facts; name explicitly that only the Communications Lead, or the Continuity Lead, posts external updates, and everyone else routes questions to them. Set an update cadence by tier, matching the cadence in the Activation Procedure above, so clients and stakeholders know when to expect their next update rather than refreshing their inbox. Silence during a disruption erodes trust faster than the disruption itself; a scheduled message confirming there's no material change yet, with a time for the next update, is often enough to hold client confidence even when there's genuinely nothing new to report. Keep a distribution list ready for each audience, internal team, active clients, key vendors, so the Communications Lead can send a single update rather than compiling contact details from memory while the clock on the next promised update is already running.

Recovery Procedures by Function

This section is where the SOP gets concrete about how each critical function from the Business Impact Analysis actually comes back online, function by function, so each Lead has a specific runbook rather than a general instruction to fix it. For Client Delivery, the Client Delivery Lead pulls the active project list, triages each project against its contractual deadline and the incident's expected duration, and applies one of three actions: continue as normal if the disruption doesn't touch that project's tools or people; switch to a documented fallback workflow, for example tracking tasks in a shared spreadsheet and communicating by email if your project platform is down; or formally pause with client notification, using the template from the Communications section, and a revised timeline once the disruption clears. For Systems & Tools, the IT/Systems Lead works through the Critical Systems list in priority order, highest-RTO functions first, attempting the documented fallback for each system before escalating to the vendor's support or escalation contact, and logging which systems are restored and when, since this log becomes the factual record for the after-action review. For Payments & Finance, the Vendor/Finance Lead confirms whether the payment processor, invoicing tool, and banking access are functional; if not, they invoke the documented fallback, a secondary processor, manual invoicing, or a delay notice to clients with a revised due date, and flag any payroll-critical deadlines that fall inside the disruption window. For People & Workspace, if the disruption affects physical access, such as an office closure or a regional event, rather than a system, the Continuity Lead confirms who can work remotely, what equipment or access they're missing, and arranges an alternate meeting point or communication rhythm for anyone without reliable remote access. Each function's recovery is considered complete only when it's restored to the RPO and RTO standard set in the Business Impact Analysis, not simply technically working again. A tool that's back online but has lost the last two hours of work has not actually recovered until that gap is reconciled or formally accepted as loss. Keep a running recovery log during any Tier 2 or Tier 3 event, timestamped entries noting when each system, vendor, and function was confirmed restored, because that log becomes both the evidence you need for any client-facing post-incident explanation and the raw material for the after-action review that follows every activation.

Testing, Drills & Review Cadence

A business continuity SOP that has never been tested is a hypothesis, not a plan, and the gap between written down and actually works only shows up under a real disruption unless you test it first. This section sets the concrete testing schedule most templates leave to 'periodically review,' which in practice means never. Run a tabletop exercise, a scenario walkthrough where the response team talks through their actions without actually executing them, at least once per quarter. Rotate the scenario each time, an infrastructure outage one quarter, a key-person unavailability the next, a vendor failure after that, so the team stays sharp across different trigger types rather than only rehearsing the one disruption that already happened once. Run at least one live drill per year, an exercise where you actually execute part of the procedure, for example genuinely failing over to your backup communication channel for a day, or having the Continuity Lead's backup run a full activation while the primary is deliberately unreachable. Live drills surface the gaps tabletop exercises miss: a phone number that's out of date, a backup account no one can actually log into, a fallback spreadsheet template that was never actually created. After every drill and every real activation, run a short after-action review and log three things: what worked, what didn't, and the specific SOP changes that follow. Feed those changes into the next revision immediately, not at the next scheduled review; an SOP that only gets updated on an annual calendar accumulates known gaps for months at a time. Set a minimum full-document review cadence of twice per year even with no incidents or drills in between, since vendors change, team members change, and RTOs that were accurate a year ago often no longer reflect how the business actually operates. Assign the review itself to a specific person and date in the Plan Maintenance section below; an undated instruction to review periodically is the single most common reason continuity plans go stale. Where possible, calendar the review the same week every cycle, for example the first week of January and July, so it survives staff turnover and doesn't quietly slip a quarter because no one remembers whose task it was.

Plan Maintenance & Version Control

This SOP is only useful if it reflects how the business actually works today, not how it worked when it was first written, so ownership and version history need to be explicit rather than assumed. Name a single Document Owner, typically the Continuity Lead, responsible for keeping this SOP current, scheduling reviews, and incorporating after-action findings from drills and real activations. Set a recurring calendar reminder for the twice-yearly review cadence from the Testing section, and add ad-hoc triggers that force an immediate update outside that schedule: onboarding a new critical vendor or tool, a change in any named role or its backup, a change in office location or remote-work policy, or any real activation of this SOP, updated within two weeks of stand-down while the lessons are still fresh. Maintain a simple version log at the top or bottom of the document: version number, date, who made the change, and a one-line summary of what changed. This log matters more than it seems during an actual incident, because it lets whoever is activating the plan quickly confirm they're looking at the current, authoritative version and not an outdated copy someone saved locally on a laptop months ago. Store the SOP somewhere that's accessible even if your primary systems are the thing that's down, a cloud document with offline access enabled, a printed copy in a physical folder, or ideally both; a continuity plan that only lives inside the system it's meant to help you recover from is a single point of failure in itself. Finally, once the SOP is drafted and reviewed, route it through a formal sign-off, the Continuity Lead and, for larger organizations, an executive sponsor, both signing to confirm the document is current, accurate, and authorized. Keep that signed version, along with a full audit trail of every prior version and its e-signature, inside a system built for it rather than a folder of loose PDFs, so you can always prove exactly which version was in force on any given date. A version log with no signatures attached is just a changelog; paired with e-signatures and an audit trail, it becomes evidence you can hand to an auditor, an enterprise customer's security team, or an insurer without having to reconstruct the plan's history from memory.