Review and improve
Plans should be reviewed when services, systems, dependencies, teams, or client requirements materially change.
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.
Continuity is not a single backup or document. It is a coordinated capability connecting people, processes, technology, suppliers, communications, and decisions.
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.
These principles are applied proportionately and remain subject to the agreed service model, risk context, client requirements, and supporting evidence.
We identify the services, people, platforms, data, and suppliers that are most important to agreed client outcomes.
Recovery planning is aligned to documented scope, technical architecture, contractual responsibilities, and available evidence.
Continuity depends on clear ownership, communication routes, access to current documentation, and suitable role coverage.
Plans should be reviewed when services, systems, dependencies, teams, or client requirements materially change.
A structured assessment helps distinguish critical capabilities from lower-priority activity and makes recovery decisions more transparent.
Clarify the client service, deliverables, operating hours, environments, data flows, hand-offs, and contractual dependencies.
Map required people, systems, cloud services, repositories, credentials, suppliers, communication channels, and client inputs.
Consider operational, financial, legal, privacy, security, reputational, and delivery effects over different disruption periods.
Determine what must be restored first, what can operate in a reduced mode, and what requires coordinated client decisions.
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.
Recovery should restore priority capabilities in a controlled sequence, with decisions and communications matched to impact.
Confirm the disruption, affected service boundary, and immediate risks.
Activate relevant owners and agreed communication routes.
Restore or re-establish priority capabilities using documented procedures.
Check service integrity, data completeness, access, and downstream dependencies.
Record lessons, actions, ownership, and plan improvements.
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.
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.
Third-party dependencies can affect technology access, specialist delivery, communication, hosting, identity, support, or data processing.
Identify which supplier supports which service component and whether a single dependency creates concentration risk.
Consider available service documentation, contractual commitments, support routes, access, and relevant due-diligence evidence.
Assess practical workarounds, substitution options, data portability, transition effort, and decisions requiring client involvement.
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:
Testing helps identify assumptions, outdated contacts, missing access, unclear ownership, unworkable procedures, and technical recovery gaps.
Check scope, contacts, dependencies, responsibilities, and recovery steps for accuracy.
Review a plausible disruption with the people who would coordinate decisions and recovery.
Where appropriate, test restoration, access, failover, data integrity, or operational workarounds.
Record findings, assign owners, prioritise changes, and update the plan after material change.
Recovery terminology is useful only when it is connected to a defined service, credible architecture, available resources, supplier capabilities, and shared responsibilities.
| Objective | What it means | How 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 Disruption | The 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. |
Engagement-specific planning works best when both parties define ownership, evidence, decisions, communication, and dependencies before disruption occurs.
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.
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.
Review related information on security, data handling, incidents, and external dependencies.
These answers are designed for procurement, legal, privacy, security, technology, data, finance, and operational stakeholders.
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.