Skip to main content
Trust Center · Business Continuity

Operational resilience for dependable data consulting delivery.

Our business continuity approach helps us prepare for disruption, protect priority work, coordinate recovery, and maintain clear responsibilities across data consulting, analytics, engineering, AI, cloud, reporting, and managed data engagements.

This page describes our approach and common planning considerations. Contractual commitments, recovery objectives, and service-specific controls must be agreed for the relevant engagement.

Executive summary

A practical continuity framework built around client outcomes

Continuity is not a single backup or document. It is a coordinated capability connecting people, processes, technology, suppliers, communications, and decisions.

How we frame continuity

We begin by understanding what the engagement must deliver, which dependencies support that delivery, and what disruption could mean for the client. We then consider proportionate prevention, response, recovery, validation, and improvement activities.

For data and AI work, this may include source systems, pipelines, cloud platforms, repositories, reporting environments, model workflows, access controls, project documentation, specialist knowledge, and client-owned dependencies.

Operational resilience principles

Principles that guide continuity planning

These principles are applied proportionately and remain subject to the agreed service model, risk context, client requirements, and supporting evidence.

Prioritise critical services

We identify the services, people, platforms, data, and suppliers that are most important to agreed client outcomes.

Design for practical recovery

Recovery planning is aligned to documented scope, technical architecture, contractual responsibilities, and available evidence.

Plan for human continuity

Continuity depends on clear ownership, communication routes, access to current documentation, and suitable role coverage.

Review and improve

Plans should be reviewed when services, systems, dependencies, teams, or client requirements materially change.

Business impact and dependency assessment

Understand what must continue and what it depends on

A structured assessment helps distinguish critical capabilities from lower-priority activity and makes recovery decisions more transparent.

01

Define the service boundary

Clarify the client service, deliverables, operating hours, environments, data flows, hand-offs, and contractual dependencies.

02

Identify critical dependencies

Map required people, systems, cloud services, repositories, credentials, suppliers, communication channels, and client inputs.

03

Assess disruption impact

Consider operational, financial, legal, privacy, security, reputational, and delivery effects over different disruption periods.

04

Prioritise recovery actions

Determine what must be restored first, what can operate in a reduced mode, and what requires coordinated client decisions.

Backup strategy

Backups should match the service, data, and operating model

A responsible backup strategy considers what must be protected, where it is stored, who operates the platform, how frequently data changes, and how restoration would be validated.

  • Defined scope: systems, repositories, configuration, documentation, and data included in backup arrangements.
  • Appropriate retention: retention and disposal aligned to contractual, operational, privacy, and legal considerations.
  • Controlled access: backup access subject to security roles and the technical capabilities of the relevant platform.
  • Restoration evidence: restoration procedures and tests considered where applicable to the service.
Recovery approach

A coordinated path from disruption to validated service

Recovery should restore priority capabilities in a controlled sequence, with decisions and communications matched to impact.

Recognise

Confirm the disruption, affected service boundary, and immediate risks.

Coordinate

Activate relevant owners and agreed communication routes.

Recover

Restore or re-establish priority capabilities using documented procedures.

Validate

Check service integrity, data completeness, access, and downstream dependencies.

Learn

Record lessons, actions, ownership, and plan improvements.

Infrastructure and provider resilience

Design choices should reflect provider and architecture realities

Continuity may depend on cloud platforms, hosting, source control, identity, communication, monitoring, data tools, or other technology providers. Our approach considers available provider capabilities, geographic or service design where relevant, documented support paths, and realistic alternatives.

Provider services and commitments are governed by their own terms. We do not imply control over third-party availability or recovery performance.

Workforce and communication continuity

People, access, and communication are part of recovery

Depending on scope, continuity planning may include defined owners, role coverage, controlled access to project materials, handover expectations, communication trees, escalation contacts, and alternative working arrangements.

Communication plans should identify who needs to know, what can be shared, which channel is appropriate, and who can make operational or client-impacting decisions.

Critical supplier dependencies

Continuity extends beyond our direct operating boundary

Third-party dependencies can affect technology access, specialist delivery, communication, hosting, identity, support, or data processing.

Dependency mapping

Identify which supplier supports which service component and whether a single dependency creates concentration risk.

Assurance and terms

Consider available service documentation, contractual commitments, support routes, access, and relevant due-diligence evidence.

Fallback considerations

Assess practical workarounds, substitution options, data portability, transition effort, and decisions requiring client involvement.

Project documentation and knowledge continuity

Current documentation reduces avoidable recovery friction

Continuity is stronger when authorised team members can understand the service without relying on one person’s memory. Depending on scope, project knowledge may be maintained through:

  • Architecture notes, data-flow diagrams, system inventories, and environment information.
  • Runbooks, operating procedures, issue logs, decision records, and escalation guidance.
  • Data dictionaries, model documentation, pipeline ownership, report definitions, and dependency records.
  • Version-controlled code and configuration with access limited to approved roles.
Testing, review, and improvement

Continuity plans should evolve with the service

Testing helps identify assumptions, outdated contacts, missing access, unclear ownership, unworkable procedures, and technical recovery gaps.

Document review

Check scope, contacts, dependencies, responsibilities, and recovery steps for accuracy.

Walkthrough

Review a plausible disruption with the people who would coordinate decisions and recovery.

Technical validation

Where appropriate, test restoration, access, failover, data integrity, or operational workarounds.

Improvement actions

Record findings, assign owners, prioritise changes, and update the plan after material change.

Publication limitation: testing scope and frequency vary by engagement. No universal exercise schedule, pass rate, or recovery performance is claimed on this page.
Recovery objectives explained

Objectives must be specific, supportable, and agreed

Recovery terminology is useful only when it is connected to a defined service, credible architecture, available resources, supplier capabilities, and shared responsibilities.

ObjectiveWhat it meansHow it should be applied
Recovery Time Objective (RTO)A target duration for restoring a service or capability after a disruption.RTO values should be agreed for the relevant service and supported by architecture, staffing, supplier, and contractual evidence.
Recovery Point Objective (RPO)A target for the maximum acceptable period of data loss measured in time.RPO depends on backup or replication design, system behaviour, data criticality, and the responsibilities of each party.
Maximum Tolerable Period of DisruptionThe point beyond which disruption may create unacceptable impact.This threshold is business-specific and should be informed by the client, relevant stakeholders, and documented impact analysis.
Client-specific continuity planning

Continuity is a shared-responsibility conversation

Engagement-specific planning works best when both parties define ownership, evidence, decisions, communication, and dependencies before disruption occurs.

Our responsibilities may include

  • Maintaining continuity arrangements for services and assets under our control.
  • Documenting agreed delivery procedures, dependencies, and escalation routes.
  • Coordinating response and recovery activities within the contracted scope.
  • Providing appropriate due-diligence information subject to confidentiality.

Client responsibilities may include

  • Maintaining continuity for client-owned systems, data, accounts, and infrastructure.
  • Providing current contacts, priorities, requirements, access, and decision owners.
  • Communicating material changes to systems, processes, risk, or business impact.
  • Reviewing and approving engagement-specific objectives and contractual commitments.
What this means for clients

Decision-useful continuity information

Clients can use this page to understand the questions we consider and the areas that may require engagement-specific evidence. During procurement or design, we can discuss relevant service boundaries, dependencies, responsibilities, documentation, recovery objectives, and communication routes.

Scope and limitations

Important considerations

This page is not a guarantee of uninterrupted service, a statement of certification, or a substitute for contract terms. Continuity measures vary by service, provider, architecture, location, client requirements, and the division of operational control.

Related Trust Center pages

Continue your due-diligence review

Review related information on security, data handling, incidents, and external dependencies.

Frequently asked questions

Business continuity questions from buyers and reviewers

These answers are designed for procurement, legal, privacy, security, technology, data, finance, and operational stakeholders.

What does business continuity mean for a data consulting company?
Business continuity is the coordinated approach used to prepare for, respond to, and recover from disruptions that could affect consulting delivery, analytics, data engineering, reporting, cloud data platforms, AI services, or managed data operations. The exact controls and responsibilities depend on the engagement scope and supporting systems.
Do you publish standard RTO or RPO values?
No universal values are stated on this page. Recovery Time Objectives and Recovery Point Objectives should be defined for the relevant service, architecture, data criticality, contractual scope, and shared responsibilities. Where applicable, engagement-specific objectives can be discussed during due diligence or solution design.
How do you identify critical business services and dependencies?
Our approach considers deliverables, data flows, people, systems, repositories, credentials, communication channels, cloud or technology providers, subcontractors where applicable, and client-supplied inputs. The depth of assessment is proportionate to the engagement and evidence available.
How are backups handled?
Backup arrangements depend on where data and systems are hosted, who operates them, the client contract, and the technical configuration. Relevant considerations may include scope, frequency, retention, access restriction, monitoring, restoration testing, and secure disposal. Verified implementation details should be confirmed for the specific service.
Are client systems included in your continuity plan?
Client-controlled systems are generally subject to the client’s own continuity arrangements unless a contract explicitly assigns us operational responsibilities. We work to clarify interfaces, dependencies, escalation routes, and evidence required from each party.
How do cloud and infrastructure providers affect continuity?
Cloud, hosting, software, communication, and identity providers can be important dependencies. Continuity planning should consider their documented service capabilities, geographic design where relevant, contractual terms, support routes, status information, and the practical options available if a provider service is disrupted.
What happens if key personnel are unavailable?
Where appropriate, continuity measures may include role coverage, documented responsibilities, controlled access to current project information, handover practices, communication trees, and cross-training. The exact model depends on project sensitivity, team design, and contractual restrictions.
How do you maintain project knowledge during disruption or staff transition?
Knowledge continuity may be supported through current documentation, version-controlled repositories, decision logs, runbooks, data dictionaries, architecture notes, issue records, and agreed handover procedures. Access remains subject to security, confidentiality, and least-privilege requirements.
How often are continuity plans tested?
Testing frequency should reflect service criticality, change rate, contractual obligations, technical risk, and management approval. Exercises may include document reviews, walkthroughs, communication tests, restoration checks, scenario exercises, or targeted technical validation. This page does not claim a universal testing schedule.
Will clients be informed during a continuity event?
Communication depends on the nature and impact of the event, applicable contractual terms, legal or regulatory duties, and agreed escalation routes. Engagements should define appropriate contacts, decision owners, notification thresholds, and secure communication methods.
How are suppliers and subcontractors considered?
Critical external dependencies may be assessed for the service they support, concentration risk, access to information, replacement options, contractual commitments, escalation paths, and available assurance evidence. The scope depends on the engagement and the supplier relationship.
Can you provide business continuity documentation during procurement?
A tailored continuity overview or relevant due-diligence response may be available subject to confidentiality, security review, and the information appropriate for the engagement. Sensitive operational details may require controlled sharing or a suitable agreement.
Does this page create a contractual continuity guarantee?
No. This page describes an approach and common considerations. Binding commitments, service levels, recovery objectives, responsibilities, exclusions, and remedies must be stated in the applicable contract, statement of work, or service documentation.
Documentation request

Request a Continuity Overview

Contact our Trust Team to discuss continuity information relevant to your procurement review, service design, risk assessment, or contractual due diligence. Sensitive details may require controlled sharing.

Contact the Trust Team