1. Purpose
The RTO/RPO Assessment Template is used to determine and document the recovery requirements for critical business services, ICT services, applications, systems, and information.
It helps the organization establish:
- RTO — Recovery Time Objective: the targeted maximum time within which a service or process should be restored after a disruption.
- RPO — Recovery Point Objective: the targeted point in time to which information should be recoverable after a disruption.
RTO and RPO should be based on business impact, risk, operational requirements, dependencies, and recovery capability, rather than arbitrary technical targets.
2. When to Use This Template
Use this assessment when:
- A new critical service is introduced.
- A business process changes significantly.
- A new application or cloud service is implemented.
- A major supplier changes.
- A Business Impact Assessment is performed.
- Disaster recovery requirements are being defined.
- Backup requirements are being established.
- Significant business or technology risks change.
- A recovery test identifies that existing objectives are unrealistic.
- Management reviews business continuity requirements.
3. RTO/RPO Definitions
Recovery Time Objective — RTO
The targeted amount of time within which a business service or technology service should be restored following a disruption.
Example:
Customer SaaS service RTO = 4 hours.
This means the organization has established a target to restore the service within four hours of the relevant disruption.
Recovery Point Objective — RPO
The targeted maximum amount of data loss measured in time that the organization is prepared to accept following a disruption.
Example:
Customer database RPO = 1 hour.
This means the recovery strategy should aim to restore data to a point no more than approximately one hour before the disruption, subject to the defined recovery method and actual capability.
4. Important Distinction
RTO and RPO measure different things.
| Metric | Question |
|---|---|
| RTO | How quickly do we need the service back? |
| RPO | How much recent data can we afford to lose? |
Example:
A SaaS platform may require:
RTO = 4 hours
RPO = 1 hour
This means:
- Service should be restored within the defined four-hour target.
- Recovery should aim to limit data loss to approximately one hour.
A service can have a short RTO but a longer RPO, or vice versa.
5. Assessment Information
| Field | Details |
|---|---|
| Assessment ID | RTO-YYYY-XXXX |
| Assessment Date | |
| Business Unit | |
| Business Owner | |
| ICT Owner | |
| Assessor | |
| Version | |
| Related BIA | |
| Related Risk Assessment | |
| Related ICT Service | |
| Related DR Plan | |
| Review Date |
6. Business Service Assessment
| Field | Assessment |
|---|---|
| Business Service | |
| Business Process | |
| Service Description | |
| Business Owner | |
| Service Criticality | Critical / High / Medium / Low |
| Primary Customers | |
| Internal Users | |
| Operating Hours | |
| Geographic Coverage | |
| Revenue Dependency | |
| Regulatory Dependency | |
| Contractual Dependency |
7. Business Impact Assessment
Assess the consequences if the service becomes unavailable.
| Impact Area | Low | Medium | High | Critical | Comments |
|---|---|---|---|---|---|
| Customer Impact | ☐ | ☐ | ☐ | ☐ | |
| Revenue Impact | ☐ | ☐ | ☐ | ☐ | |
| Operational Impact | ☐ | ☐ | ☐ | ☐ | |
| Information Security | ☐ | ☐ | ☐ | ☐ | |
| Confidentiality | ☐ | ☐ | ☐ | ☐ | |
| Integrity | ☐ | ☐ | ☐ | ☐ | |
| Availability | ☐ | ☐ | ☐ | ☐ | |
| Regulatory Impact | ☐ | ☐ | ☐ | ☐ | |
| Contractual Impact | ☐ | ☐ | ☐ | ☐ | |
| Reputation | ☐ | ☐ | ☐ | ☐ | |
| Supplier Dependency | ☐ | ☐ | ☐ | ☐ |
8. Time-Based Impact Assessment
Determine how the impact changes as the outage continues.
| Downtime | Business Impact | Customer Impact | Management Response |
|---|---|---|---|
| 0–1 hour | |||
| 1–4 hours | |||
| 4–8 hours | |||
| 8–24 hours | |||
| 1–3 days | |||
| >3 days |
This section is important because the acceptable recovery period should be based on when the business impact becomes unacceptable, not simply on what technology can recover quickly.
9. Maximum Tolerable Period of Disruption
MTPD / Maximum Tolerable Period of Disruption
Definition: The maximum period for which a business service can remain unavailable before the resulting business impact becomes unacceptable.
| Field | Assessment |
|---|---|
| Business Service | |
| Maximum tolerable disruption | |
| Business justification | |
| Consequence beyond this period | |
| Management approval |
Important Relationship
A typical relationship is:
RTO ≤ MTPD
The RTO should provide sufficient time to restore the service before the maximum tolerable disruption is reached.
10. RTO Assessment
Determine the required recovery time.
| Question | Assessment |
|---|---|
| How quickly must the service be available? | |
| When does business impact become significant? | |
| When does customer impact become unacceptable? | |
| Are contractual commitments involved? | |
| Are regulatory requirements involved? | |
| Are manual workarounds available? | |
| How long can the workaround operate? | |
| What dependencies must recover first? | |
| What recovery time is technically achievable? | |
| What recovery time is financially reasonable? |
Proposed RTO
RTO: __________________
RTO Justification
11. RPO Assessment
Determine how much data loss can be tolerated.
| Question | Assessment |
|---|---|
| What information is created or changed? | |
| How frequently does data change? | |
| How much recent data can the business tolerate losing? | |
| Would data loss affect customers? | |
| Would data loss affect financial records? | |
| Would data loss create regulatory issues? | |
| Can transactions be recreated? | |
| Are manual records available? | |
| Is point-in-time recovery available? | |
| What backup/replication capability exists? |
Proposed RPO
RPO: __________________
RPO Justification
12. Data Criticality Assessment
Different information within the same service may require different recovery requirements.
| Information | Criticality | Change Frequency | Required RPO | Recovery Method |
|---|---|---|---|---|
| Customer Database | Critical | High | 1 hour | PITR/replication |
| Customer Documents | High | Medium | 4 hours | Backup/versioning |
| Application Logs | Medium | High | 24 hours | Log storage |
| Audit Records | High | Low | 24 hours | Protected backup |
| Development Data | Low | Medium | 24 hours | Backup |
The organization should avoid assuming that every data type requires the same RPO.
13. ICT Service Assessment
| ICT Service | Business Service | Criticality | RTO | RPO |
|---|---|---|---|---|
| Production Application | Customer SaaS | Critical | ||
| Customer Database | Customer SaaS | Critical | ||
| Identity/SSO | Workforce | High | ||
| CI/CD | Product Delivery | High | ||
| Source Code Repository | Product Development | High | ||
| Monitoring | Security/Operations | High | ||
| Email/Collaboration | Business Operations | Medium |
14. Dependency Assessment
For each critical service, identify dependencies.
Dependency Chain
Business Process
↓
Business Service
↓
Application
↓
Database/Data
↓
Infrastructure
↓
Network
↓
Identity
↓
Cloud/Supplier
↓
Recovery Dependency
| Dependency | Criticality | Failure Impact | Recovery Requirement |
|---|---|---|---|
| AWS | Critical | Production unavailable | Within service RTO |
| RDS | Critical | Customer data unavailable | Within service RTO |
| Identity Provider | High | Admin/user access unavailable | |
| DNS | High | Customer access affected | |
| CI/CD | Medium/High | Deployment unavailable | |
| Payment Provider | High | Revenue process affected |
15. Recovery Strategy Assessment
| Requirement | Available Capability | Gap | Action |
|---|---|---|---|
| RTO | |||
| RPO | |||
| Backup | |||
| Replication | |||
| Failover | |||
| Alternate Environment | |||
| Infrastructure-as-Code | |||
| Emergency Access | |||
| Monitoring | |||
| Supplier Support |
16. AWS SaaS Example
Consider a SaaS company running on AWS.
Architecture:
Route 53 → CloudFront/WAF → Load Balancer → ECS → RDS → S3
Business requirement
Customer-facing SaaS service is classified as Critical.
The Business Impact Assessment determines:
- Extended outage affects customers.
- Revenue-generating activity depends on availability.
- Customer contractual commitments may be affected.
- Database transactions are business-critical.
- Manual workaround is limited.
Proposed recovery requirements
| Component | RTO | RPO |
|---|---|---|
| Customer SaaS | 4 hours | 1 hour |
| Customer Database | 4 hours | 1 hour |
| Customer Documents | 8 hours | 4 hours |
| Identity | 4 hours | 4 hours |
| Monitoring | 4 hours | 4 hours |
| Development Environment | 24 hours | 24 hours |
These values are example organizational targets, not universal requirements.
Recovery strategy
The organization may use:
- AWS backups
- RDS point-in-time recovery
- S3 versioning
- Protected backup storage
- Infrastructure-as-code
- Documented recovery procedures
- Emergency access
- Cloud monitoring
- Recovery testing
The organization must then test whether these capabilities can actually meet the defined RTO/RPO.
17. RTO/RPO Feasibility Assessment
A target should not be approved simply because the business wants it.
Assess whether it is achievable.
| Factor | Assessment |
|---|---|
| Technology capability | |
| Backup frequency | |
| Replication capability | |
| Network capacity | |
| Recovery environment | |
| Staff availability | |
| Supplier capability | |
| Cloud provider capability | |
| Recovery procedure maturity | |
| Testing results | |
| Cost | |
| Complexity | |
| Security requirements |
Feasibility Result
☐ Achievable
☐ Achievable with improvements
☐ Currently not achievable
☐ Requires management risk acceptance
18. Gap Assessment
Compare the required target with the demonstrated capability.
| Metric | Required | Current Capability | Gap |
|---|---|---|---|
| RTO | 4 hrs | 6 hrs | 2 hrs |
| RPO | 1 hr | 4 hrs | 3 hrs |
| Backup frequency | 1 hr | 4 hrs | 3 hrs |
| Recovery environment | Required | Not available | Gap |
| Recovery test | Required | Not tested | Gap |
Each material gap should be linked to:
- Risk Assessment
- Corrective Action
- Recovery Improvement
- Management Decision
- Risk Acceptance where appropriate
19. RTO/RPO Approval
Business Owner
Name: __________________________
Decision:
☐ Approved
☐ Approved with Conditions
☐ Not Approved
Signature/Approval: __________________
Date: __________________
ICT Owner
Name: __________________________
Decision:
☐ Technically Achievable
☐ Achievable With Improvement
☐ Not Currently Achievable
Comments:
Security/BCP Review
Name: __________________________
Comments:
20. Recovery Test Validation
RTO and RPO should be validated through testing where practical.
| Test | Target | Actual | Result |
|---|---|---|---|
| Service Recovery | 4 hrs | ||
| Database Recovery | 4 hrs | ||
| Data Recovery Point | 1 hr | ||
| Application Validation | Required | ||
| Security Validation | Required | ||
| Business Validation | Required |
Test Evidence
- Test ID:
- Test Date:
- Test Scenario:
- Recovery Start:
- Recovery Complete:
- Data Recovery Point:
- Evidence Location:
- Findings:
- Corrective Actions:
- Retest Required:
21. RTO/RPO Deviation
Where actual recovery does not meet the approved target:
- Record the deviation.
- Determine the reason.
- Assess business and security impact.
- Determine whether the target remains appropriate.
- Create corrective action where necessary.
- Obtain management decision if required.
- Reassess risk.
- Retest after improvement.
Example:
Approved RTO = 4 hours
Actual recovery = 6 hours
The organization should not simply change the RTO to six hours to make the test appear successful.
Instead:
Target → Actual Result → Gap → Risk → Corrective Action → Improvement → Retest
22. RTO/RPO Review Triggers
Review the assessment when:
- Business processes change.
- Customer requirements change.
- New regulatory obligations arise.
- Architecture changes.
- Cloud architecture changes.
- Critical suppliers change.
- Data volumes materially increase.
- Backup strategy changes.
- Major incidents occur.
- DR tests identify significant gaps.
- Recovery performance changes.
- New critical applications are introduced.
- Business impact changes.
23. RTO/RPO Master Register
Maintain a central register.
| ID | Business Service | ICT Service | Criticality | RTO | RPO | Owner | Last Test | Status |
|---|---|---|---|---|---|---|---|---|
| RTO-001 | Customer SaaS | Production | Critical | 4h | 1h | Active | ||
| RTO-002 | Customer Data | RDS | Critical | 4h | 1h | Active | ||
| RTO-003 | Identity | SSO | High | 4h | 4h | Active | ||
| RTO-004 | Development | CI/CD | High | 8h | 4h | Active | ||
| RTO-005 | Collaboration | SaaS | Medium | 8h | 24h | Active |
24. Management Review
Management should periodically review:
- Critical services
- Approved RTO/RPO
- Recovery capability
- Actual recovery performance
- Failed tests
- Significant deviations
- Recovery investment requirements
- Supplier dependencies
- Major business changes
- Outstanding corrective actions
- Residual risk
Management decisions should be recorded.
25. Startup Implementation
A startup can keep the assessment simple.
Start with the top 5–10 critical services.
For each service, answer:
- What happens if this service stops?
- How quickly must it be restored?
- How much recent data can we afford to lose?
- What systems does it depend on?
- How will we recover it?
- Can we actually achieve the target?
- When was it last tested?
- What happens if the target cannot be achieved?
A practical spreadsheet can contain:
Service → Owner → Criticality → RTO → RPO → Dependencies → Recovery Method → Last Test → Actual RTO → Actual RPO → Gap → Corrective Action
26. ISO/IEC 27001 Alignment
RTO/RPO assessment supports the organization’s risk-based business continuity and ICT readiness arrangements.
It can provide evidence supporting areas such as:
- ICT readiness for business continuity
- Information security during disruption
- Backup
- Redundancy
- Incident management
- Risk treatment
- Business continuity testing
- Supplier and cloud continuity
- Information availability and resilience
ISO/IEC 27001 does not prescribe one universal RTO or RPO value for every organization. The organization should determine appropriate recovery requirements based on its business needs, risks, dependencies, and recovery objectives.
27. Audit Evidence
An auditor should be able to trace:
Business Service
→ Business Impact
→ MTPD
→ Required RTO/RPO
→ Risk Assessment
→ Recovery Strategy
→ Technical Capability
→ Recovery Test
→ Actual RTO/RPO
→ Gap
→ Corrective Action
→ Risk Reassessment
→ Management Decision
For example:
Customer SaaS
→ Critical
→ MTPD 8 hours
→ RTO 4 hours
→ RPO 1 hour
→ AWS recovery strategy
→ DR test
→ Actual RTO 3h 35m / RPO 42m
→ Target achieved
→ Evidence retained
→ Management review
28. Final Audit Trail
Business Service Identified
→ Business Impact Assessed
→ Criticality Determined
→ MTPD Established
→ RTO Requirement Defined
→ RPO Requirement Defined
→ Dependencies Identified
→ Recovery Capability Assessed
→ Feasibility Evaluated
→ Management Approval
→ Recovery Strategy Implemented
→ Recovery Tested
→ Actual RTO/RPO Measured
→ Gap Identified
→ Corrective Action Assigned
→ Risk Reassessed
→ Retest Performed
→ Management Review
29. Final Principle
RTO/RPO should not be numbers selected because they sound reasonable. They should be evidence-based recovery requirements derived from business impact, risk, information criticality, dependencies, and demonstrated recovery capability.
Understand the Business Impact + Define the Recovery Requirement + Assess Feasibility + Build the Capability + Test It + Measure Actual Performance + Correct the Gaps + Reassess Risk.