1. Purpose
The Cloud Backup and Recovery Procedure defines how the organization identifies information and systems requiring backup, configures and protects backups, monitors backup operations, tests restoration, and recovers cloud services following data loss, corruption, accidental deletion, security incidents, or service disruption.
The procedure is intended to support:
- Availability of critical information and systems
- Recovery from accidental deletion or corruption
- Recovery from cybersecurity incidents
- Business continuity
- Disaster recovery
- Protection against ransomware and destructive attacks
- Customer-service continuity
- Data integrity
- Regulatory and contractual requirements
Backup and recovery requirements should be determined based on business impact, information classification, recovery requirements, risk assessment, contractual commitments, and applicable ISMS controls.
2. Scope
This procedure applies to cloud-hosted:
- Databases
- Object storage
- Virtual machines
- Containers and workloads
- Application data
- Configuration data
- Infrastructure-as-Code
- Cloud configurations
- Critical application repositories
- Security logs where retention requires backup
- Customer information
- Personal information
- Business-critical SaaS data
- Cloud infrastructure supporting production services
- Backup services and repositories
It may apply to IaaS, PaaS, SaaS, private cloud, public cloud, and hybrid cloud environments.
3. Key Principle
Cloud backup should not be treated simply as:
“The cloud provider has backups.”
The organization should determine:
What needs protection → What can be recovered → How often it is backed up → Where backups are stored → Who can access them → How long they are retained → How restoration works → How restoration is tested → What evidence exists
4. Backup and Recovery Lifecycle
The organization’s lifecycle should follow:
Identify → Classify → Determine Recovery Requirements → Define Backup Strategy → Configure → Protect → Monitor → Test → Recover → Verify → Improve
5. Definitions
Backup
A copy of information, configuration, or system state maintained so that the original can be restored following loss, corruption, deletion, compromise, or disruption.
Recovery
The process of restoring information, systems, applications, and services to an acceptable operational state.
RPO — Recovery Point Objective
The maximum acceptable amount of data loss measured in time.
Example:
RPO = 1 hour means the organization aims to recover data to a point no more than approximately one hour before the disruption, subject to the actual recovery capability.
RTO — Recovery Time Objective
The target time within which a service or system should be restored following disruption.
Example:
RTO = 4 hours means the organization targets restoration within four hours.
RPO and RTO values should be defined based on business requirements rather than automatically applying the same value to every system.
6. Roles and Responsibilities
| Role | Responsibility |
|---|---|
| Business Owner | Determines business recovery requirements |
| System/Application Owner | Identifies systems and data requiring backup |
| Cloud/DevOps Team | Configures and maintains cloud backups |
| Security Team | Reviews backup security and access controls |
| IT/Infrastructure Team | Supports restoration and recovery |
| Privacy/Data Owner | Reviews personal-data backup and retention requirements |
| Business Continuity Owner | Coordinates continuity and recovery requirements |
| Incident Manager | Coordinates recovery during security incidents |
| Management | Approves major recovery requirements and risk decisions |
In a startup, multiple responsibilities may be performed by the same person.
7. Identify Information and Systems Requiring Backup
The organization should identify systems and information where loss, corruption, or unavailability could materially affect the business.
Examples include:
- Production databases
- Customer information
- Transaction records
- Application configuration
- Critical source code
- Infrastructure configuration
- Security configuration
- Business-critical documents
- Financial information
- Critical SaaS data
- Encryption/key-management configuration where recoverable
- Monitoring/security configuration
- Critical audit records where appropriate
Not every temporary, public, or easily reproducible piece of information necessarily requires the same backup strategy.
8. Information Classification and Criticality
Backup requirements should consider:
- Information classification
- Business criticality
- Customer impact
- Personal-data requirements
- Regulatory requirements
- Contractual requirements
- Recovery dependencies
- Availability requirements
- Integrity requirements
- Acceptable data loss
Example:
| Information | Criticality | Illustrative RPO | Illustrative RTO |
|---|---|---|---|
| Production customer database | Critical | 1 hour | 4 hours |
| Application configuration | High | 24 hours | 8 hours |
| Development environment | Medium | 24 hours | 24 hours |
| Temporary development data | Low | As required | As required |
These values are examples only. Actual targets should be approved by the relevant business/system owners.
9. Backup Strategy
The backup strategy should define:
- What is backed up
- Backup frequency
- Backup method
- Backup location
- Retention period
- Encryption
- Access control
- Backup integrity protection
- Restoration method
- Restoration testing frequency
- Backup monitoring
- Failure escalation
- Responsibilities
Backup configurations should be reviewed when systems or business requirements change.
10. Backup Frequency
Backup frequency should be based on the RPO and business requirements.
Possible approaches include:
- Continuous replication
- Point-in-time recovery
- Hourly backups
- Daily backups
- Weekly backups
- Monthly backups
- Event-based backups
- Pre-change backups
For example, a critical production database may require frequent automated snapshots or point-in-time recovery, while a low-criticality development system may only require daily backups.
11. Backup Protection
Backups should be protected against unauthorized access, modification, destruction, and inappropriate disclosure.
Appropriate controls may include:
- Encryption
- Strong authentication
- Least-privilege access
- Separate backup permissions
- Restricted administrative access
- MFA
- Backup immutability where appropriate
- Versioning
- Retention controls
- Monitoring
- Logging
- Segregation from production access
The organization should consider the risk that an attacker who compromises production administrative access could also delete or encrypt backups.
12. Backup Isolation
Where appropriate, critical backups should have protection that limits an attacker’s ability to compromise both production systems and backups.
Possible measures include:
- Separate backup accounts
- Separate administrative roles
- Separate backup repositories
- Cross-account backup copies
- Immutable backups
- Object lock or equivalent protection
- Restricted deletion permissions
- MFA for sensitive backup operations
- Approval for destructive backup actions
The appropriate architecture should be based on risk and recovery requirements.
13. Encryption
Backup data should be encrypted where required by:
- Information classification
- Risk assessment
- Customer requirements
- Contractual requirements
- Legal or regulatory obligations
- Security policy
Encryption should be considered both:
- At rest
- In transit
Where customer-managed encryption keys are used, the organization should ensure that key-management arrangements do not create an unnecessary single point of failure for recovery.
14. Backup Access Control
Access to backups should be restricted to authorized personnel and systems.
The organization should review:
- Backup administrators
- Recovery administrators
- Service accounts
- Automation roles
- Cross-account access
- Third-party access
- Emergency access
- API credentials
Privileged backup access should be controlled and monitored.
Backup administrators should not automatically receive unrestricted production access.
15. Backup Monitoring
Backup operations should be monitored to identify:
- Failed backups
- Incomplete backups
- Unexpected backup deletion
- Storage capacity issues
- Encryption failures
- Configuration changes
- Retention failures
- Unauthorized access
- Replication failures
- Backup repository availability issues
Critical backup failures should generate appropriate alerts and corrective actions.
A backup job showing “successful” should not automatically be treated as proof that the organization can recover the system.
16. Backup Verification
The organization should periodically verify that backups are:
- Completing successfully
- Accessible to authorized personnel
- Within required retention periods
- Protected from unauthorized access
- Consistent with expected scope
- Recoverable
- Not corrupted
- Available when required
Verification may include:
- Automated backup validation
- Checksum/hash validation where applicable
- Backup integrity checks
- Test restoration
- Database consistency checks
- Recovery exercises
17. Restoration Testing
Restoration should be tested periodically based on system criticality and risk.
A restoration test should demonstrate that the organization can actually recover the required information or system.
A test may include:
- Select the backup.
- Create an isolated recovery environment.
- Restore the information/system.
- Validate integrity.
- Start required services.
- Validate application functionality.
- Verify data consistency.
- Measure restoration time.
- Compare actual recovery with RTO/RPO.
- Record results.
- Document failures.
- Assign corrective actions.
18. Recovery Test Evidence
Evidence may include:
- Backup ID
- Backup date/time
- Restore date/time
- Source system
- Target recovery environment
- Data restored
- RPO achieved
- RTO achieved
- Validation results
- Screenshots/logs
- Test owner
- Findings
- Corrective actions
- Approval
The objective is to demonstrate:
The backup exists and the organization can actually restore from it.
19. Recovery Scenarios
The recovery procedure should consider scenarios such as:
Accidental deletion
Restore the required information from the most appropriate backup or point-in-time recovery source.
Data corruption
Identify the corruption point and restore from a known-good recovery point.
Ransomware
Do not automatically restore from the latest backup.
First determine whether the backup may also be compromised.
Use a known-good recovery point and validate the restored environment.
Compromised cloud account
Secure the account and investigate before performing recovery.
Ensure that the attacker cannot continue accessing or deleting backups.
Cloud service disruption
Activate appropriate continuity/recovery arrangements based on service criticality.
Region or infrastructure failure
Use the approved resilience/recovery architecture where applicable.
Application failure
Restore application data and supporting configuration and validate dependencies.
20. Recovery During a Security Incident
When recovery is required following a cybersecurity incident, the incident-response process should coordinate with backup and recovery.
The organization should:
- Contain the incident.
- Preserve evidence.
- Determine what systems are trustworthy.
- Identify clean recovery points.
- Confirm backup integrity.
- Secure recovery credentials.
- Restore systems.
- Patch or harden affected systems.
- Validate security controls.
- Restore service.
- Monitor for recurrence.
Recovery should not reintroduce the original vulnerability or compromised configuration.
21. AWS Example
Consider a SaaS company operating its production environment on AWS.
The environment contains:
- Amazon RDS production database
- Amazon S3 customer documents
- ECS application workloads
- Application configuration
- Secrets Manager
- Infrastructure-as-Code
- Cloud monitoring configuration
A practical backup strategy could include:
RDS
Use automated backups and point-in-time recovery according to the approved RPO.
S3
Use appropriate versioning, retention, replication, and access controls based on business and data requirements.
Infrastructure
Maintain Infrastructure-as-Code in a controlled repository so infrastructure can be recreated rather than relying solely on machine snapshots.
Critical backups
Where risk warrants, maintain protected backup copies with separate permissions or accounts.
Security
Restrict backup deletion and administrative access using least privilege and MFA.
Recovery test
Periodically restore an RDS database into an isolated environment and verify:
- Database integrity
- Application connectivity
- Data consistency
- Recovery time
- Recovery point
- Security configuration
Evidence should be retained for the test.
22. SaaS Application Recovery
For a SaaS application, backup should not focus only on the database.
The organization should consider dependencies such as:
Application → Database → Object Storage → Secrets → IAM → Network → DNS → CI/CD → Monitoring → Backup
For example, restoring an RDS database alone may not recover the complete SaaS service if:
- Application configuration is missing.
- Secrets are unavailable.
- Infrastructure cannot be recreated.
- DNS configuration is missing.
- Deployment pipelines are unavailable.
- IAM permissions are incorrect.
Therefore, recovery should be tested at the service level where appropriate.
23. Recovery Dependencies
Before declaring recovery complete, identify dependencies such as:
- Identity provider
- DNS
- Network
- Cloud provider
- Database
- Storage
- Secrets management
- Encryption keys
- CI/CD
- Container registry
- Third-party APIs
- Monitoring
- Security services
Critical dependencies should be considered in business continuity and disaster recovery planning.
24. Data Retention and Backup Deletion
Backup retention should consider:
- Business requirements
- Information classification
- Legal requirements
- Regulatory requirements
- Customer contracts
- Privacy requirements
- Recovery requirements
- Storage costs
Backup copies containing personal information should not automatically be retained indefinitely.
Where information must be deleted, the organization should understand how deletion interacts with:
- Backup retention
- Immutable backups
- Replication
- Disaster recovery copies
- Legal holds
The organization should document an appropriate approach.
25. Backup and Recovery Changes
Changes to backup configurations should follow the organization’s change-management process where applicable.
Examples include:
- Changing backup frequency
- Changing retention
- Changing backup location
- Changing encryption
- Changing recovery architecture
- Disabling backups
- Changing recovery roles
- Changing RPO/RTO
- Moving to another backup provider
Changes affecting critical systems should include appropriate risk assessment and validation.
26. Backup Failure Management
When a critical backup fails:
- Identify the failure.
- Determine the affected system/data.
- Assess whether the required recovery point is still available.
- Investigate the cause.
- Correct the backup configuration.
- Perform a successful backup.
- Verify the backup.
- Escalate if recovery requirements are at risk.
- Record the event and corrective action.
Repeated backup failures should be treated as a risk rather than simply individual technical tickets.
27. Backup Exceptions
If a system cannot meet the approved backup requirement, the exception should be documented.
The exception should include:
- System
- Business owner
- Requirement
- Reason for exception
- Risk
- Compensating controls
- Target remediation date
- Risk acceptance, where applicable
- Approval
- Review date
Exceptions should be time-bound where practical.
28. Startup-Friendly Implementation
A startup does not need a complex enterprise backup platform from day one.
A practical minimum model is:
Critical production data
- Automated backup
- Appropriate retention
- Encryption
- Restricted access
- Monitoring
- Tested restoration
Application recovery
- Source code repository
- Infrastructure-as-Code
- Configuration management
- Secrets recovery process
- Deployment capability
Critical systems
Define:
- RPO
- RTO
- Backup owner
- Recovery owner
- Backup location
- Retention
- Recovery test frequency
Evidence
Maintain:
- Backup configuration
- Backup success/failure records
- Restore test records
- Recovery results
- Corrective actions
- Approvals
As the organization grows, additional capabilities can include cross-region recovery, isolated backup accounts, immutable storage, automated recovery testing, and dedicated disaster-recovery environments.
29. Records and Evidence
Typical records include:
- Backup inventory
- Backup configuration
- Backup schedule
- Backup success/failure logs
- Backup monitoring alerts
- Backup retention configuration
- Encryption configuration
- Backup access list
- Recovery requirements
- RPO/RTO register
- Restoration test records
- Recovery exercise reports
- Recovery incidents
- Corrective actions
- Backup exceptions
- Risk assessments
- Change records
- Recovery approvals
Sensitive credentials should never be stored in backup registers or recovery documentation.
30. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Business Continuity Policy | Establishes continuity requirements |
| Business Continuity Plan | Defines business response to disruption |
| Disaster Recovery Plan | Defines technical recovery |
| Cloud Security Policy | Defines cloud-security requirements |
| Cloud Secure Configuration Standard | Defines secure cloud configuration |
| Cloud Security Risk Assessment | Identifies cloud-related risks |
| Cloud Incident Response Procedure | Coordinates recovery following security incidents |
| Cloud Services Register | Identifies cloud services requiring consideration |
| Critical Technology Dependency Assessment | Identifies critical technology dependencies |
| Cloud Exit Checklist | Supports migration or termination |
| Risk Register | Tracks significant backup/recovery risks |
| Change Management Procedure | Controls material backup/recovery changes |
31. Internal Audit Checklist
An auditor can verify:
- Critical systems requiring backup are identified.
- Backup requirements are based on business/risk requirements.
- RPO and RTO are defined where appropriate.
- Backup frequency is documented.
- Backup retention is defined.
- Backups are appropriately protected.
- Backup access is restricted.
- MFA is applied to privileged access where appropriate.
- Backup operations are monitored.
- Backup failures are investigated.
- Backup integrity is verified.
- Restoration tests are performed.
- Recovery results are documented.
- RTO/RPO performance is evaluated.
- Critical dependencies are considered.
- Security incidents include recovery considerations.
- Backup exceptions are documented and approved.
- Backup configurations are controlled through change management.
- Personal/customer information in backups is appropriately governed.
- Corrective actions from failed recovery tests are tracked.
32. ISO 27001 Connection
Cloud backup and recovery should support applicable information-security, availability, resilience, backup, and cloud-security requirements identified through the organization’s ISMS.
The implementation should follow:
Business Requirement → Information/System Criticality → Risk Assessment → Recovery Requirement → Control Selection → Implementation → Testing → Evidence → Continual Improvement
A backup policy or successful backup job alone does not demonstrate effective recovery capability.
For audit purposes, stronger evidence is:
Requirement → Backup Configuration → Successful Backup → Protected Backup → Restoration Test → Recovery Validation → Corrective Action
33. Final Cloud Backup and Recovery Audit Trail
A complete lifecycle should produce a traceable chain:
System/Data Identified
→ Criticality Determined
→ RPO/RTO Defined
→ Backup Requirement Established
→ Backup Strategy Approved
→ Backup Configured
→ Encryption/Access Controls Applied
→ Backup Executed
→ Backup Monitored
→ Backup Verified
→ Restoration Tested
→ Recovery Results Recorded
→ Findings Identified
→ Corrective Actions Assigned
→ Recovery Capability Improved
→ Periodic Review
For an actual recovery event:
Incident/Disruption
→ Recovery Decision
→ Recovery Point Selected
→ Backup Integrity Verified
→ Recovery Environment Prepared
→ Data/System Restored
→ Security Controls Validated
→ Application Tested
→ Business Service Verified
→ Stakeholders Informed
→ Recovery Completed
→ Lessons Learned
→ Corrective Actions
34. Final Principle
Effective Cloud Backup and Recovery = Appropriate Backup + Protected Copies + Defined RPO/RTO + Tested Restoration + Verified Recovery + Evidence
The key audit question is not:
“Do you have backups?”
It is:
“Can you demonstrate that the right information and systems are backed up, that the backups are protected, and that you have actually tested your ability to recover the required service within the organization’s defined recovery requirements?”