Services / Business Continuity Planning
This is a difficult, expensive and organizationally disruptive programme.
If it were straightforward, organizations would not consistently fail at it.
The reason most business continuity plans do not work when tested and completely fail during real incidents which is not because no one tried.
It is because the programme is genuinely hard where the dependencies are more complex than assumed, the stakeholders are harder to align than expected, the recovery tests reveal failures no one predicted and the maintenance discipline required to keep the plan current outlasts the organizational appetite that commissioned it.
We do not sell a simple solution to a complex problem.
We execute a structured programme that addresses the problem at its structural root which means confronting, not avoiding, every point where the programme is likely to encounter resistance, failure or deviation.
Every stage of this programme has a defined protocol for when things go wrong, because things will go wrong.
The Zero Is Not Null™ principle is not optimism.
It is the engineering of a balanced state where (+failure) + (−recovery) = 0.
Achieving that balance is expensive, slow and requires sustained commitment from both parties.
The alternative of null, the absence of any genuine recovery capability costs more, eventually, in a way you cannot control and cannot time.
Price Range
£32,000 to £280,000+
Fixed per tier. Scope extensions priced separately before execution.
Fixed per tier. Scope extensions priced separately before execution.
Duration
12 weeks minimum · 14+ months for enterprise
Timelines assume full client cooperation per obligations below. Delays caused by client side blockers extend the programme accordingly.
Timelines assume full client cooperation per obligations below. Delays caused by client side blockers extend the programme accordingly.
Tiers
Essential · Professional · Enterprise
Tier determined at discovery session, not from this page.
Tier determined at discovery session, not from this page.
Contract
Fixed-price. 50% on signing. 50% on final deliverable acceptance. Scope extensions invoiced separately at agreed rates.
Risk
Both parties carry obligations. Programme failure is most commonly caused by client side failures: unavailable stakeholders, blocked system access, deferred board decisions. These are documented in the programme contract.
Read before enquiringThis programme requires active, sustained participation from your IT team, your process owners and your senior leadership throughout its duration. It cannot be delegated entirely to a consultant. If your organization cannot currently provide that participation, the programme will not succeed and should not be started.
Why This Programme Is Difficult
What you will encounter at every stage which none of it is optional to resolve.
These are not edge cases but they are the normal operating conditions of a business continuity programme in any real organization and where consultancies that do not tell you about them in advance are the reason the industry has such a poor track record, we describe them here because a client who is prepared for them can respond to them correctly, a client who encounters them as surprises typically responds by pausing the programme, deferring decisions or losing confidence in the process all of which make the outcome worse.
Stage 1 — Dependency Mapping
The infrastructure is more complex and less documented than anyone believes
In every engagement, the actual dependency architecture discovered during investigation differs significantly from what IT leadership believed it to be. Shadow IT systems are operationally critical and not in any asset register. Cloud services are in use by departments with no IT governance involvement. Suppliers have sub processors who carry dependencies not visible in the primary contract. Shared network circuits are assumed to be independent. The investigation always takes longer than planned because organizations consistently underestimate their own complexity.
What this means for your programmeThe dependency map takes longer to complete than the initial estimate. Every discovery of an undocumented system or dependency adds scope to subsequent stages. Systems you did not know existed will need RTOs, runbooks and recovery procedures. This is not a failure of the programme but it is the programme functioning correctly by revealing what was previously hidden. But it has cost and timeline implications.
Our protocol when this occursWe document every discovery immediately. We assess whether it materially affects the programme scope. If it does, we present you with a written scope adjustment and cost impact before proceeding. You approve or descope. Nothing proceeds without your written agreement on any scope change that affects cost or timeline.
Stage 1 to 2 — Stakeholder Access
The people who hold critical knowledge are the hardest to access
Process owners are busy. IT staff are managing live systems and incidents. Senior managers defer scheduling. The individuals whose knowledge is most essential to the dependency map and the BIA are typically the least available for interviews. This is the single most common cause of programme delays. A dependency investigation that should take 2 weeks takes 5 because interviews are repeatedly rescheduled. A BIA that requires 10 process owner interviews takes 4 weeks because 4 of the 10 people cannot be made available within the window.
What this means for your programmeTimeline extensions caused by stakeholder unavailability are not covered by the fixed price. They extend the programme duration but do not change the total fee, provided the delay does not require us to re execute completed stages. If delays are extended enough to require re mapping of changed infrastructure, that constitutes a scope change.
Our protocol when this occursEach programme stage has a defined stakeholder availability requirement agreed before that stage begins. If availability cannot be confirmed within 5 business days of a stage start, we invoke the delay protocol where programme is formally paused, written notice is issued, timeline is adjusted. We do not proceed with incomplete information and produce a plan that will fail because it was built on gaps.
Stage 2 — Business Impact Analysis
The financial impact of downtime is almost always higher than leadership expects and they resist the findings
The BIA consistently produces impact figures that are uncomfortable. When the model shows that 4 hours of ERP downtime costs £380,000 in direct loss plus regulatory exposure, the instinct is to challenge the methodology rather than accept the finding and act on it. When the model shows that 20 of 25 processes have RTOs under 4 hours, the instinct is to adjust the RTOs upward to make the recovery architecture cheaper, not to fund the architecture that the genuine RTOs require. This pressure produces plans that are costed to what the organisation wants to spend, not what genuine resilience requires. We have seen this dynamic in every sector.
What this means for your programmeIf the BIA findings are overridden by commercial pressure to reduce RTOs or narrow scope, the resulting plan will be designed to a standard lower than the organization’s actual risk requires. We will document this explicitly. The gap between the genuine RTOs and the commercially adjusted RTOs will appear in the programme record. If an incident subsequently exposes that gap, the documentation will show that the organization was informed of it and chose to accept it.
Our protocol when this occursWe present BIA findings as they are calculated. We do not adjust findings to fit preferred budget conclusions. If the organization wishes to proceed with a narrower scope or adjusted RTOs, we document the decision, the original findings and the residual risk in writing. This is signed by the authorizing manager. We then execute the programme against the approved scope. We will not execute a programme whose scope we believe is structurally inadequate without this documented acknowledgement.
Stage 3 — Recovery Architecture
The architecture that meets the RTOs costs significantly more than the organisation budgeted
Recovery architecture costs are not the programme fee but they are the infrastructure investment required to implement the recovery capability. Synchronous mirroring for a Tier 0 system costs money to implement. Cloud DR infrastructure for Tier 1 systems costs money to provision and maintain. These are implementation costs outside our programme fee, to be procured and deployed by your team or an infrastructure partner. In our experience, organisations that have not modelled these costs in advance experience significant budget shock when they see the architecture design. In some cases, the implementation costs are multiple times the programme fee itself.
What this means for your programmeWe provide the architecture design and specification. We do not procure or implement infrastructure. The cost of implementation is entirely separate from and additional to the programme fee. We will provide cost estimates for the infrastructure components in the architecture design but these are estimates and actual procurement costs depend on your vendor negotiations, existing contracts and market conditions at the time of procurement.
Our protocol when this occursStage 3 includes a cost benefit analysis that presents the implementation cost estimate alongside the avoided cost calculation from the BIA. This gives the board a genuine decision framework. If the implementation cost exceeds what can be approved, we redesign the architecture to fit the available budget but we document explicitly which RTOs cannot be met at that budget level and what the residual risk is. The board signs off on the budget constrained architecture with full knowledge of the gap.
Stage 4 — Documentation
Review cycles expand. Sign off is harder to obtain than expected. Documents get revised into ambiguity.
Documentation review cycles are consistently underestimated. A runbook reviewed by 4 people produces 4 sets of conflicting comments, some of which contradict each other and some of which reflect preferences rather than accuracy. Legal and compliance teams request changes that trade operational clarity for legal precision and making the document safer to sign but harder to execute under pressure. Senior managers request modifications that soften language around their team’s obligations. IT staff flag procedures that require system access they don’t currently have. Every comment is a potential delay, and not every comment should be accepted.
What this means for your programmeThe programme includes 2 rounds of revisions per document. If review cycles produce fundamental challenges to the analytical basis of a document and not editorial preferences but substantive disputes about what the recovery procedure should be which this may require re execution of the relevant analysis stage at additional cost. Unlimited revision rounds are not included and will be priced at our day rate if requested.
Our protocol when this occursWe distinguish between two categories of comment where factual corrections (incorporated without discussion) and preference modifications (discussed and either incorporated or declined with reasoning). We will decline changes that we believe compromise the operational effectiveness of a document but we will explain why in writing. If the client insists on changes we believe are harmful, we implement them and document our objection. We will not produce a document we believe will fail in use without a written record of having said so.
Stage 5 — Testing
Recovery tests fail. Repeatedly. This is not a sign that the programme has failed.
The first technical recovery test almost never achieves its RTO target. Backups are incomplete. Application configurations differ between primary and recovery environments. Dependencies that were not in the architecture specification exist in the production environment and are missing from the recovery environment. DNS propagation takes longer than the RTO allows. The recovery team encounters an error state that the runbook does not cover. Every failure reveals something real about the gap between the recovery architecture as designed and the recovery capability as it actually exists. This is the test functioning correctly. The problem is not the failure but it is if the failure is not found until a real incident.
What this means for your programmeThe programme includes one full round of initial testing per tier. When tests fail and they will where we identify the root cause, design the remediation and re test. Remediations that require architecture changes or additional infrastructure may incur additional cost. Remediations that require only procedure changes or configuration corrections are included. There is no cap on the number of re-tests for issues identified in the initial test round. We do not sign off a test as passed until the RTO target has been achieved under realistic conditions.
Our protocol when tests failEvery failed test produces a written root cause analysis within 48 hours. The root cause is classified where RJV analytical error (our cost to remediate), infrastructure gap (implementation cost borne by client), procedure gap (our cost to remediate) or scope boundary issue (discussed and agreed). A revised test is scheduled within 10 business days of remediation completion. All test failures, their root causes and the subsequent remediation are documented in the evidence pack and a clean evidence pack that shows no failures occurred is a sign of insufficient testing rigor, not programme quality.
Stage 6 — Maintenance
Organisations lose the discipline to maintain the programme within 6 months of completion
This is the most predictable failure mode in business continuity. The programme completes. The documentation is filed. The maintenance responsibilities assigned to named individuals are not resourced, not prioritized and not enforced. Infrastructure changes occur without triggering plan reviews. Staff leave recovery critical roles without knowledge transfer. Suppliers change. Regulatory requirements evolve. Within 12 to 18 months, the plan reflects an organisation that no longer exists in the form the plan assumes. The plan becomes a liability where it satisfies auditors while creating false confidence about a recovery capability that has silently degraded.
What this means for your programmeA plan that is not actively maintained will be wrong within 12–18 months for most organisations. It will satisfy compliance requirements for longer than that where auditors review documentation, not operational reality. But the gap between documented capability and actual capability will grow until an incident reveals it. We cannot force maintenance discipline on an organization. We can only design the maintenance programme, deliver it to you and make explicit what happens when it is not followed.
Our protocol for maintenanceThe programme concludes with a written maintenance responsibility matrix which named individuals, specific obligations, defined trigger conditions and calendar review dates. We offer an annual maintenance retainer (priced separately) that includes trigger based reviews, an annual exercise and the structural discipline that most organizations cannot sustain internally. For organizations that cannot commit to the maintenance retainer, we explicitly document that the programme’s operational effectiveness has a finite lifespan without it and we record that this was communicated.
Throughout — Organisational Resistance
Parts of the organisation will actively resist the programme
Business continuity programmes expose uncomfortable truths where undocumented systems, ignored dependencies, processes held together by specific individuals who have not documented anything, suppliers whose resilience commitments are contractually empty and recovery time objectives that the board assumed were being met but are not. The people whose areas are exposed by these findings have an interest in the findings not being prominent. IT leaders whose estate is revealed to be more fragile than they reported to the board resist the dependency mapping findings. Finance directors whose processes have 4-hour MTPs argue that 48 hours is more realistic. Department heads who should own response guides argue that their function is not critical. This resistance is not malice but it is the normal human response to exposure. But it delays and degrades the programme if not managed.
What this means for your programmeThe programme requires a named executive sponsor with sufficient authority to override departmental resistance to findings. Without this, we will encounter delays, diluted findings and a programme that concludes with a plan that everyone was comfortable with but that does not reflect reality. If we reach a point in the programme where we believe organisational resistance has materially compromised the analytical integrity of the work, we will say so in writing before proceeding further.
Our protocol when resistance occursWe report resistance to the named executive sponsor immediately and in writing. We do not attempt to negotiate around it informally. The sponsor has the authority and the obligation to resolve it. If the sponsor cannot or will not resolve specific instances of resistance, we document the resulting gap in the programme and proceed with the agreed reduced scope. We do not absorb political pressure by softening findings.
Bilateral Obligations
Both parties carry obligations and both parties carry consequences for failing them.
These obligations are contractual as they appear in the programme agreement before any work begins which we present them here in full so that they are understood before the discovery session, not after the contract is signed, our programme engagement is not a transaction where you pay a fee and receive a product but it is a joint undertaking where the quality of the outcome depends on both parties meeting their obligations throughout.
Client Obligations And Commitments
Named executive sponsor at C-suite or equivalent
A single named individual with budget authority, sufficient organizational authority to direct departmental cooperation, and the time to receive programme updates and make decisions when they are required. This person must be reachable within 2 business days for programme decisions.
If not provided or not engagedProgramme proceeds to the point where a decision requires sponsor authority, then formally pauses. Timeline adjusts. No cost implication unless the pause exceeds 15 business days, at which point re mobilization fees apply.
Named IT lead available for investigation phases
A technical staff member with knowledge of the production infrastructure who can be scheduled for a total of 10–35 hours depending on tier across the dependency mapping and testing phases. Interviews must be scheduled within 5 business days of our request. Access must be arranged to the systems listed in the pre-programme access document.
If unavailable within agreed windowsStage is paused. Formal notice issued. For every 5 business days of delay caused by unavailability, the programme end date extends by 5 business days. If unavailability extends beyond 20 business days, a re mobilization fee applies equal to 5% of the programme fee.
Process owner interviews with all named individuals
Every named process owner must attend their scheduled BIA interview. Interviews are 90 minutes. We require 5 business days notice to reschedule. No substitution without prior agreement where a substitute who does not own the process cannot provide the information required. If a specific individual’s knowledge is critical and they are unavailable, we will document that the BIA for their process is built on incomplete information.
If an interview cannot be completedThe BIA for that process will be flagged as incomplete. The resulting RTO and recovery procedures for that process will carry an explicit uncertainty notation. The programme proceeds, but the incompleteness is documented and does not disappear from the final deliverables.
System access as specified pre-programme
Read-only access to: network documentation, cloud billing consoles, infrastructure configuration management tools, monitoring dashboards, third party contracts and SLAs and any systems on the agreed access list. Access must be provisioned before the relevant stage begins, not during it. Access provisioning delays are a common and significant source of programme delay.
If access is delayed or withheldThe affected investigation stage pauses until access is provisioned. The programme timeline adjusts accordingly. If access is withheld to a system that is subsequently discovered to be operationally critical, the programme must revisit earlier stages at additional cost.
Document review within 5 business days
Each deliverable sent for review must receive written comments within 5 business days. If the reviewing individual cannot complete the review in this window, they must nominate a qualified substitute or formally extend the review window in writing. Reviews submitted after the deadline extend the programme timeline by the number of days late.
If reviews are not returnedAfter 10 business days without response, the document is considered approved as submitted. This is documented in the programme record. If the client later disputes a document on grounds that would have been caught in review, the record shows the review window passed without response.
Board strategy approval within agreed window
The recovery strategy and architecture require board level approval before documentation and implementation begin. This is not a formality where the board must understand what they are approving, including the implementation costs, the RTOs achievable within the approved budget and the residual risk at that budget level. Board approval cannot be delegated below the sponsoring executive without our written agreement.
If board approval is deferredProgramme formally pauses after 15 business days without board engagement. Full pause protocol applies. If the board subsequently approves a materially different scope from what was presented, the stages following the strategy presentation must be re executed at cost.
Maintenance obligations post-delivery
Within 30 days of programme completion, you must assign named owners to each plan component with documented responsibilities. You must record trigger events as they occur and initiate reviews within 5 business days of a trigger. You must conduct the annual review either with RJV (retainer) or independently with documentation that the review occurred. These are your obligations regardless of whether you engage RJV for ongoing support.
If maintenance is not performedThe programme documentation becomes a snapshot of an organization that no longer exists as described. We will not represent that the programme remains current if maintenance has not been conducted. If you use RJV documentation in a regulatory submission after a maintenance window has been missed, we require you to note the maintenance gap in the submission.
RJV Obligations And Our Commitments
Named senior consultant as single point of accountability
A named senior consultant is assigned as programme lead before contract signature. This person leads the dependency investigation, presents BIA findings to the board, oversees all documentation, and is accountable for overall programme quality. Substitution of the named lead requires your written agreement. If we must substitute the lead, we provide 10 business days notice and ensure a full knowledge transfer before the new lead takes over.
If we fail this obligationIf the named lead is substituted without your agreement and this causes demonstrable programme disruption, we will credit the cost of the re mobilization period against the final invoice.
All findings reported as found, not as preferred
We report what the investigation reveals including findings that are uncomfortable for the organization, that contradict what IT leadership has reported to the board, or that imply higher costs than the programme budget anticipated. We do not soften findings to ease client relationships. Every finding is documented in full. Every risk is rated at the level it warrants, not at a level that is comfortable.
If you believe we have softened a findingYou have the right to request the analytical basis for any finding’s rating. We will provide it in full. If you believe a finding has been materially understated, raise it in writing within 10 business days of receiving the relevant document and we will review it with you.
Scope changes agreed before execution, never after
If the programme scope changes for any reason with discovery of additional systems, regulatory requirement changes, organizational restructuring where we present a written scope change document before executing any work on the additional scope. The scope change document names the addition, the reason, the cost impact and the timeline impact. We do not execute scope additions and invoice for them retrospectively.
If we execute scope additions without prior agreementYou are not obligated to pay for work performed outside the agreed scope without a signed scope change document. This is a hard contractual commitment, not a goodwill gesture.
Failed tests remediated at our cost where the failure is our error
If a technical recovery test fails because our runbook contained an error, our architecture specification was incorrect or our analysis produced a wrong RTO target, the remediation and re test are at our cost. We distinguish rigorously between failures caused by our analytical errors and failures caused by infrastructure gaps, missing implementation or scope items that were deliberately excluded. Our error = our cost. Infrastructure gap = additional cost to client.
If we dispute the error classificationClassification disputes are resolved by written mutual agreement. If agreement cannot be reached within 10 business days, an independent technical reviewer (agreed by both parties) reviews the failed test and assigns classification. Their determination is binding on both parties.
Explicit documentation of every limitation, gap, and risk
Every limitation of the programme where scope boundaries, assumptions that could not be verified, RTOs that were adjusted for budget reasons, processes where the BIA was incomplete, tests that were not conducted which appears explicitly in the final programme documentation. We do not produce deliverables that imply completeness they do not possess. The gap register is a standing document, not an afterthought.
If we fail to document a known limitationIf you discover in a subsequent audit or incident that we were aware of a material limitation and did not document it, you have grounds for a remediation claim. We maintain internal programme notes throughout that can be disclosed to establish what we knew and when.
Fixed price honoured regardless of programme complexity
The programme fee does not increase because the engagement is more complex than anticipated, takes longer than planned due to factors within our control, requires more iterations to produce satisfactory deliverables or requires additional test rounds to achieve passing results. The only legitimate grounds for additional cost are scope additions you approve, client caused delays exceeding the re mobilization thresholds or infrastructure gaps explicitly excluded from the original scope.
If we raise an invoice beyond the agreed programme feeAny invoice above the agreed programme fee must reference the specific scope change document or delay protocol clause that authorizes it. You are not obligated to pay any additional sum that cannot be traced to a signed scope change or an invoked delay clause.
Honest assessment at discovery including recommending against engagement
If the discovery session reveals that your organization is not currently in a position to execute this programme successfully due to insufficient IT resource, absent executive sponsorship, regulatory timeline that makes a full programme impractical or an existing BCP that genuinely needs only maintenance not replacement then we will say so. We will recommend the audit product, a phased approach or in some cases no engagement at all. We do not commence a programme we believe will fail in order to collect the fee.
If we commence and later determine the programme cannot succeedIf circumstances change during the programme such that successful completion becomes impossible for reasons outside both parties’ control, we will notify you in writing, present options (pause, descope, terminate) and agree a position on fees for completed stages only.
Programme Tiers with Scope, Price and Timeline
Three Tiers With Fixed Prices, Named Deliverables And Named Exclusions.
The timelines below assume full client cooperation as defined in the obligations section where every week of delay caused by client side unavailability, deferred decisions or blocked access extends the programme end date by the equivalent period and where these timelines are not guarantees but they are the outcome when both parties meet their obligations, when they do not, the timeline extends and both parties know why.
Tier 1 — Essential
Essential Programme
For organizations up to 200 staff, single primary site, up to 3 critical systems in scope, one regulatory framework. Typical organizations are independent schools, GP practices and small healthcare providers, SME manufacturers, small charities, single site professional services firms. If you have more than 3 systems with sub 4 hour RTOs or more than one active regulatory framework, you are in Tier 2.
£32,000
Fixed · VAT excl.
12 weeks baselineAssumes full client cooperation per obligations. Delays extend this proportionally.
Analysis & Architecture
Dependency mapping is up to 25 systems, 3 third party suppliers
BIA are up to 8 critical processes with financial impact modelling
RTO and RPO per system which is derived from actual impact model
Recovery tier classification for all 25 systems
Architecture design for 3 highest criticality systems only
1 regulatory framework mapped (ISO 22301 or DSPT Std. 9 or NIS2 and client selects)
Multi site dependency analysis
Third party SLA contractual gap analysis
Documents Produced
Master BCP is 10 to 30 pages
IT response guide (step by step, system specific)
Operations response guide
Technical runbooks are up to 3 critical systems (command level)
Manual downtime procedures are up to 3 critical systems
Crisis communication framework with internal stakeholders only
Incident decision tree are only 3 scenario types
Regulatory notification timeline for selected framework
External stakeholder communication framework
Board investment pack with cost benefit analysis
Testing & Evidence
1 × tabletop exercise with half day, 2 scenarios, RJV facilitated
1 × technical recovery test with 1 system in isolated environment
Measured RTO achievement documented
Written test results and gap register
Compliance evidence pack for selected framework
30 day post delivery support (email only)
Full simulation exercise
Third party supplier resilience testing
Annual review (available separately from £8,500)
Baseline Timeline — 12 Weeks (client obligations met in full)
Wk 1 to 2
Dependency Mapping
Infrastructure review, IT lead interviews (6 hrs), shadow IT scan, documentation review.
Common delay is IT lead unavailable, access not provisioned. Extension: 1 day per day of delay.
Wk 3 to 4
Business Impact Analysis
8 process interviews (2 hrs each), impact modelling, RTO/RPO derivation, sponsor briefing.
Common delay is process owners cancel interviews. If any interview is not completed, that process’s BIA is flagged incomplete.
Wk 5 to 6
Strategy & Architecture
Recovery tier design. Architecture for 3 Tier 0 to 1 systems. Board approval required before proceeding.
Common delay is board approval deferred. Programme pauses after 15 business days without decision.
Wk 7 to 9
Documentation
All documents drafted and issued for review. 5 business days per document for client review. 1 revision round included.
Common delay is reviews returned late or with conflicting comments. Each day of review delay extends delivery by 1 day.
Wk 10 to 11
Testing
Tabletop exercise. Technical recovery test. All failures root cause analyzed and remediated before sign off.
Common delay is test reveals infrastructure gap requiring procurement. Remediation timeline depends on procurement speed which is outside of our control.
Wk 12
Handover
Final deliverables, evidence pack, maintenance programme handover, 2 hour staff walkthrough.
Final invoice raised on written acceptance. Acceptance cannot be withheld on grounds not raised during review cycles.
What Your Team Must Provide (contractual)
Named IT lead where is available for 6 hours total in weeks 1 to 2, scheduled in 2 hour blocks with minimum 3 business days notice
8 named process owners is available for one 90 minute interview each in weeks 3 to 4, scheduled minimum 5 business days in advance, no substitution without prior written agreement
Named executive sponsor is available for 2 hour briefing in week 4 and 1 hour board approval session in week 6
System access provisioned before week 1 begins: read-only access to infrastructure documentation, cloud billing console, network diagrams, third party contracts
IT lead available for 4 hour window during technical recovery test (week 10 to 11), scheduled minimum 10 business days in advance
Document reviews returned within 5 business days of issue
What Is Not in This Tier (must be separately procured if required)
Implementation of any recovery infrastructure identified in the architecture design which this is the client’s cost, separate from and additional to the programme fee
ISO 22301 certification body fees (if certification is the objective) are typically from £4,000 to £9,000 additional
Recovery tests for systems 4 to 25 (only 1 system tested in this tier)
Second or third regulatory framework mapping
External stakeholder communication framework and regulatory notification templates beyond the selected framework
Post Year 1 annual review is available at £8,500/year
On call incident support after the 30 day post delivery window is available at £3,200/month
Tier 2 — Professional
Professional Programme
For organizations of 200 to 1,500 staff, up to 5 sites, up to 15 critical systems with RTOs under 8 hours, up to 3 concurrent regulatory frameworks. Typical organizations: NHS Trusts and integrated care organizations, mid size financial services firms, multi site manufacturers, universities, local authorities, housing associations. If you operate above these thresholds, you are in Tier 3.
£95,000
Fixed · VAT excl.
22 weeks baselineAssumes full client cooperation. Delays extend proportionally. Re mobilization fee applies after 20 business days of cumulative delay.
Analysis & Architecture
Dependency mapping is up to 80 systems across all sites
Third party dependency mapping is up to 12 critical suppliers
Multi site failure isolation analysis
BIA is up to 25 critical processes, all business units
RTO and RPO with financial derivation per system
Recovery tier classification is for all 80 systems
Full architecture design across all tiers
Up to 3 regulatory frameworks simultaneously
Third party SLA gap analysis under 12 suppliers
OT/IT convergence analysis (manufacturing/CNI)
DORA TLPT programme design
Documents Produced
Master BCP with 60 to 100 pages
6 × role specific response guides (IT, Ops, Finance, HR, Legal, Comms)
Technical runbooks is for all Tier 0 to 2 systems
Manual downtime procedures: all Tier 0 to 1 systems
Crisis communication with internal + external stakeholders
8 × incident decision trees, all major scenario types
Regulatory notification templates is all 3 frameworks
Third party resilience register and contractual gap report
Board investment pack with cost benefit analysis per tier
ISO 22301 certification ready documentation
Testing & Evidence
2 × tabletop exercises are full day each, 4 scenarios each
Technical recovery tests is for all Tier 0 and Tier 1 systems
1 × full simulation exercise is a half day, multi function
Measured RTO/RPO for all tested systems
Compliance evidence packs is for all 3 frameworks
60 day post delivery support with email + 2 × scheduled video calls
Year 1 annual review included in programme price
Year 2+ annual reviews (£8,500 per year thereafter)
On call incident retainer beyond 60 day window (£1,200/month)
Baseline Timeline — 22 Weeks (client obligations met in full)
Wk 1 to 4
Multi-Site Dependency Mapping
Technical investigation across all sites. 80-system survey, 12 supplier assessments, up to 15 staff interviews.
This stage has the highest risk of delay. Multi-site access provisioning typically encounters IT governance friction. Allow additional 1 to 2 weeks buffer if your organisation has complex access provisioning.
Wk 5 to 7
Business Impact Analysis
25-process impact modelling. Multi site cascade analysis. Board presentation of findings and full RTO/RPO matrix.
Budget shock is common at this stage. Boards resist high impact findings. Allow 1 week for board digestion before strategy discussion.
Wk 8 to 10
Architecture & Strategy
Full architecture design. All tiers specified. 3 framework compliance mapping. Board strategy approval required to proceed.
Board approval is the single most common cause of Tier 2 timeline extension. If board meeting cycle is monthly, build 4 weeks buffer here.
Wk 11 to 16
Documentation
All plans, guides, runbooks. Two review cycles per document. Function lead sign off on relevant guides.
6 weeks for documentation in a 1,900 per person organisation is aggressive. Legal and compliance review often adds 1 to 2 weeks beyond what operations review requires.
Wk 17 to 20
Testing Programme
2 tabletops, technical recovery tests for all Tier 0 to 1 systems, full simulation exercise.
First recovery tests for Tier 0 systems frequently reveal infrastructure gaps requiring remediation. Each gap that requires procurement extends the test window. Budget 2 additional weeks for this.
Wk 21 to 22
Handover
All deliverables, 3 × evidence packs, maintenance programme documentation, full team walkthrough (4 hours).
Final invoice on written acceptance. Acceptance withheld on grounds not raised in review cycles is a contractual dispute.
What Your Team Must Provide (contractual)
Named IT lead from more or less 25 to 35 hours total, distributed across weeks 1 to 4 and 17 to 20 in agreed scheduled blocks
Up to 15 named process and department owners: 90 minutes each, weeks 5 to 7, no substitution without prior agreement
Named executive sponsor with board presentation availability in week 7, strategy approval session in week 9 to 10
6 named function leads with 2 hours each to review their role specific response guide, week 14 to 15
System access provisioned before week 1 is for all items on the pre programme access list
IT team availability during recovery test windows (weeks 17 to 20) under half day blocks, scheduled minimum 10 business days in advance
Additional Costs Not in This Tier
All recovery infrastructure implementation is designed by RJV, procured and deployed by client or infrastructure partner at separate cost
ISO 22301 certification body from typically £6,000 to £14,000 additional depending on certification body and scope
DORA TLPT execution is available separately, cost depends on scope and accredited provider
4th regulatory framework and beyond is priced as scope addition before execution
Re mobilization fee if cumulative client caused delays exceed 20 business days with 5% of programme fee
Systems or suppliers discovered during the programme beyond the 80 system per 12 supplier ceiling where the scope change, priced and approved before execution
Tier 3 — Enterprise
Enterprise Programme
For organizations above 1,500 staff, multiple sites or jurisdictions, more than 15 critical systems with sub 8 hour RTOs, ISO 22301 certification target, DORA TLPT requirement or critical national infrastructure designation. All enterprise engagements are individually scoped at the discovery session. The price and timeline below are starting points where the actual programme scope, price and timeline are agreed in writing before contract signature.
From £280,000
Individually scoped · Fixed on agreement · VAT excl.
From 9 monthsComplex enterprise programmes routinely run 12 to 18 months. The discovery session defines the realistic timeline for your specific situation.
Analysis & Architecture
Full enterprise dependency mapping with no system ceiling
Multi jurisdiction supply chain mapping with Tier 1 and Tier 2 suppliers
BIA across all business units and all critical processes
All regulatory frameworks applicable with no cap
Important Business Service mapping (FCA PS21/3 / DORA)
Impact tolerance framework with regulator ready evidence
DORA third party ICT concentration risk register
OT/IT coverage for manufacturing or CNI operators
ISO 22301 gap analysis and full certification preparation
Documents Produced
Enterprise Master BCP with subsidiary plans by site/division
Full function response guide suite with all departments
Runbooks is for all Tier 0 to 2 systems across all sites
Manual downtime procedures is for all Tier 0 to 1 systems
Multi audience crisis framework (regulator, board, press, customers, suppliers)
Pre drafted regulatory notifications are all applicable frameworks
DORA documentation suite (Arts. 11 to 14, 17, 24 to 26)
ISO 22301 BCMS documentation for certification audit
Board and audit committee reporting templates
Testing & Evidence
4 × tabletop exercises across 2 years
Technical recovery tests is for all Tier 0 to 2 systems
2 × full simulation exercises are multi site, multi function
DORA TLPT programme design (significant entities)
ISO 22301 pre certification audit and remediation
Evidence packs is all applicable frameworks
2 year maintenance programme included
On call advisory retainer during incidents of 12 months
TLPT execution with accredited TLPT provider procured separately
Year 3+ maintenance is available at agreed retainer rate
Enterprise Specific Requirements
Named C suite programme sponsor with budget authority and board access and this is a nonnegotiable requirement for an enterprise programme
Dedicated internal programme coordinator (does not need to be technical but must have authority to schedule access across all departments)
Quarterly steering committee meetings with programme sponsor, IT leadership and legal compliance with minimum of 2 hours per quarter
All site IT leads available for investigation phases across all locations with travel and logistics for multi site access agreed pre-programme
Legal and compliance team availability for regulatory framework sign off where typically the most time constrained resource in enterprise engagements
Why Enterprise Programmes Run Longer Than Expected
Board meeting cycles mean strategic decisions take 4 to 6 weeks longer than in smaller organizations and build this into your planning
Legal review of documentation in regulated enterprises commonly adds 3 to 5 weeks to documentation phases
ISO 22301 pre certification audits typically reveal remediation requirements that add 6 to 10 weeks to the programme
Recovery tests for critical systems in production constrained environments (NHS, financial trading) require maintenance windows that may be scheduled months in advance
Organizational restructuring during a multi month programme is common and may require partial re execution of completed stages
Standalone Service
Continuity Audit
You have an existing BCP and need to know honestly whether it would work. Or you have just experienced an incident that exposed gaps. Or you are preparing a regulatory submission and want an independent assessment before you submit. This does not commit you to a programme engagement.
£9,500
Fixed · VAT exclusive
3 to 4 weeks
What the Audit Examines
Whether stated RTO/RPO targets are achievable given the current infrastructure or are estimates without engineering basis
Whether the dependency map in the plan matches the actual production environment
Whether the runbooks are executable by someone without institutional context from the original author
Which specific regulatory clauses are not met, with exact evidence required to close each gap
Whether the plan has been maintained: last review date, trigger events that occurred and were not acted on, staff changes that created unaddressed gaps
Whether the testing evidence presented in the plan is from realistic tests or from tests designed to pass
What the Audit Produces
Written findings report with 15 to 25 pages, severity rated findings, specific regulatory clause references
Prioritized remediation list where each finding with the specific action required to close it and an estimate of the cost and time to do so
Assessment of whether the existing plan can be updated or must be rebuilt with the reasoning stated explicitly
1 hour findings presentation with your IT leadership and senior management
The audit report is yours. Use it however you choose, including submitting it to a regulator as evidence of due diligence. We do not soften audit findings because you may subsequently engage us for a programme.
Questions that should be asked before any contract is signed
We already have a BCP. Can’t you just update it?
Possibly. But “updating” a BCP that has fundamental structural problems with wrong RTOs, missing dependencies, untested procedures which produces a document that looks updated but contains the same failures in a newer format. The audit (£9,500) is the right first step. It tells you whether your plan can be updated or needs to be rebuilt. We will not tell you it can be updated if it cannot because doing so benefits us commercially in the short term and produces a bad outcome for you when an incident happens.
The timeline seems long. Can it be compressed?
Not without removing stages or reducing scope. The timelines are the minimum required to do the work properly and not the time we prefer to spend but the time that the work takes when it is done correctly. Any consultant who offers you a business continuity programme in 4 weeks is selling you a template, not a programme. If you have a genuine regulatory deadline, raise it at the discovery session and we will assess honestly whether a compliant programme can be delivered within it. If it cannot, we will say so rather than promise a delivery we cannot make.
What if the infrastructure costs to implement the architecture are too high?
Then we redesign the architecture to fit the available budget and document explicitly which RTOs cannot be met at that level. You will know precisely what risk you are accepting and why. What we will not do is design an architecture that appears to meet your RTOs but is priced to a level that cannot actually implement it. The cost-benefit analysis in Stage 3 is designed to give you this decision clearly before any implementation costs are incurred.
What happens if the programme is delayed by our side?
The programme timeline extends by the equivalent of the delay. For delays under 20 cumulative business days, there is no additional fee which the programme resumes where it paused. For delays beyond 20 cumulative business days, a re mobilization fee equal to 5% of the programme fee applies per additional 10 business days of delay. This is because our team’s capacity is allocated to your programme and cannot be reallocated during a pause without a commercial consequence.
Our IT team is very small. Is this realistic?
A small IT team is a risk factor, not a disqualifier. The dependency mapping and testing stages will impose a real burden on a small IT team which in Tier 1, approximately 10 to 14 hours over 12 weeks. If those hours cannot be freed during the programme period, the programme will run over schedule. Before signing, you should be realistic about whether your IT lead can genuinely provide those hours alongside their operational responsibilities. If they cannot, the programme should be scheduled for a lower pressure period or we should discuss a phased approach.
What if we experience a real incident during the programme?
The programme formally pauses. The incident takes priority. We are available as advisory support during the incident if you request it which this is separate from and not part of the programme fee. After the incident is resolved, we resume the programme. If the incident reveals gaps in the dependency map or BIA that were being worked on, the relevant stages may need to be partially re executed. The incident evidence becomes part of the programme record but it is direct evidence of the gaps the programme was already designed to address.
What does the maintenance obligation actually require after delivery?
Named owners for each plan component must be assigned within 30 days of delivery. Any significant infrastructure change, new critical supplier, departure of a recovery critical staff member or regulatory change triggers a plan review within 5 business days of the trigger event. An annual review must occur which either with RJV (£8,500per year) or independently with a written record that the review happened and what it found. If none of this happens, the plan will be wrong within 12–18 months. We cannot enforce it but we can only tell you it will happen if you do not.
Can you guarantee that our RTO targets will be met after the programme?
We can guarantee that the recovery procedures we design and test will achieve the RTO targets under the conditions that existed during testing. We cannot guarantee performance under conditions that differ materially from the test environment with a real ransomware attack is not the same as a controlled recovery test. What we can guarantee is that you will know what was tested, under what conditions with what results and where the gaps remain. That is the honest boundary of what a BCP programme can deliver. Anyone who guarantees more than this is misrepresenting what the product can do.
The discovery session is free. It is also the most useful conversation to have before you have a reason to have it urgently.
90 minutes.
We ask about your current continuity arrangements, your regulatory obligations, your infrastructure, and your incident history.
If you bring an existing BCP, we review it in the session.
At the end, you have an honest assessment of where you are and not a sales pitch for where you should be.
If a programme is appropriate and you are in a position to execute it, we will say so and follow up with a fixed price scope.
If you are not in a position to execute a programme now, we will say that instead.
Format
Video call or in person in London. 90 minutes.
Cost
Free. No commitment, no follow-up sales process unless you request one.
Lead time
Typically within 5 business days of first contact.
Bring
Any existing BCP, DR plan or continuity documentation. Your current regulatory compliance obligations. Any incidents from the last 24 months that are relevant.
Attendees
Your side: the IT lead or CTO and whoever has accountability for regulatory compliance. Our side we as senior consultants. Not a salesperson.
After
Written summary of what the session found within 2 business days. Written scope and fixed price within 5 business days if a programme is appropriate and you want to proceed.
Sectors