GASP AICF

Search controls and profiles

Search by control ID, name, domain or profile

BCM-003 RTO and RPO Definitions

Tier 2+ProviderDeployerGPAI Model ProviderManaged Service Provider

Description

Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) are defined for each critical service and system. RTOs and RPOs are formally agreed with business owners, documented in the BCP and DRP, and communicated to relevant teams. Objectives are validated against contractual and regulatory commitments.

Rationale

Without agreed RTO/RPO targets, recovery efforts lack measurable goals. Defined and communicated objectives enable planning, testing, and SLA management.

Applicability (9 profiles)

SaaS AI Providerstablerequiredcore
Enterprise AI Deployerstablerequiredcore
GPAI Model Providerstablerequiredcore
High-Risk Provider (EU)stablerequiredcore
Public Body Deployer (EU)stablerequiredcore
DORA ICT Provider (EU)stablerequiredcore
NIS2 Cloud Provider (EU)stablerequiredcore

Framework Mappings (9)

BCR-02Risk Assessment and Impact Analysisfull
BCR-03Business Continuity Strategyinformative
BCR-02Risk Assessment and Impact Analysisfull
BCR-03Business Continuity Strategyinformative
HIPAA-164.308.a.7.ii.BDisaster Recovery Planinformative
5.30ICT readiness for business continuityinformative
NIS2-CIR-12.1Asset Classificationinformative
CP-2Contingency Planpartial
CP-2(3)Contingency Plan | Resume Mission and Business Functionsfull

Evidence (2)

recorddocumentmanual

RTO and RPO definitions for each critical service, formally agreed with business owners and documented in the BCP and DRP.

Example: Service recovery objectives register or BCP annex listing each critical service with its agreed RTO, RPO, approving business owner, and date of last review

Test: Request the RTO/RPO register and compare against the BCP and DRP. Verify: (1) RTOs and RPOs are defined for all services listed in the critical service register; (2) each objective is signed off by a named business owner; (3) values are consistent between the register, BCP, and DRP; (4) objectives are validated against any applicable contractual or SLA commitments.

policydocumentmanual

Business continuity strategy or impact analysis document used as the basis for setting RTOs and RPOs, demonstrating objectives are derived from formal risk and impact assessment.

Example: Business Impact Analysis (BIA) report or BCM strategy document listing assessment outputs for each critical service, including maximum tolerable downtime and data loss tolerance, mapped to agreed RTO/RPO values

Test: Request the Business Impact Analysis or BCM strategy document. Verify: (1) a BIA or equivalent analysis was conducted; (2) the analysis covers all services in the critical service register; (3) RTO and RPO values in the register are traceable to outputs from the BIA; (4) the BIA was completed within the last defined review cycle.

Questions (2)

boolean

Are recovery time objectives and recovery point objectives defined for each critical service?

RTOs and RPOs must be explicitly defined, not inferred from backup frequency or infrastructure configuration. Each objective should be signed off by a named business owner.

multi

Which of the following apply to your recovery time and recovery point objectives?

Each objective is agreed with a named business ownerThey are recorded in the business continuity plan and the disaster recovery planThey are communicated to the teams that would carry out the recoveryThey are validated against contractual availability commitmentsThey are validated against regulatory commitmentsNone of the above

Options run from the most commonly in place to the least. The control requires the objectives to be defined and agreed, not any particular number. An objective the recovery team has never seen is a commitment made on their behalf.