Backup & Restore Procedure

1. Purpose

The Backup & Restore Procedure defines how the organization identifies, protects, performs, monitors, tests, restores, and securely disposes of backups for critical information and technology services.

The procedure is designed to ensure that the organization can:

Recover critical information after loss, corruption, deletion, or disruption.
Support approved RPO requirements.
Protect backups against unauthorized access or destruction.
Recover from ransomware and other security incidents.
Restore critical ICT services.
Validate the integrity and usability of restored information.
Demonstrate that backup and restoration capabilities actually work.
Maintain appropriate audit evidence.

2. Scope

This procedure applies to backups of:

Production databases
Customer information
Application data
File and object storage
Source code
Infrastructure configuration
Infrastructure-as-code
Critical SaaS data
Security logs where required
Application configuration
Secrets/configuration where appropriate
Backup configuration
Critical system images or recovery artifacts

It applies to:

Cloud environments
On-premises systems where applicable
SaaS platforms
Databases
Applications
Endpoints where business-critical
Recovery environments
Critical technology suppliers

3. Backup Principles

The organization shall apply the following principles.

Business-driven

Backup requirements should be based on information criticality, risk, RPO, and business requirements.

Secure

Backups must be protected against unauthorized access, modification, and deletion.

Recoverable

A backup is useful only if it can be successfully restored.

Independent

Where appropriate, backups should be protected from failure or compromise of the production environment.

Monitored

Backup jobs and failures should be monitored.

Tested

Restoration should be periodically tested based on risk and criticality.

Traceable

Backup and restore activities should generate appropriate records and evidence.

Minimized

Backup retention should not result in unnecessary retention of sensitive information.

4. Backup Strategy

The organization should define:

What information is backed up.
Why it is backed up.
Backup frequency.
Retention period.
Storage location.
Protection requirements.
Encryption.
Recovery method.
Restoration priority.
RPO.
Testing frequency.
Owner.

5. Backup Register

Maintain a central Backup Register.

Backup ID	System/Data	Criticality	Backup Type	Frequency	RPO	Storage	Status
BK-001	Customer DB	Critical	PITR/Snapshot	Continuous/Daily	1h	AWS	Active
BK-002	Customer Documents	High	Versioned Backup	Daily	24h	AWS	Active
BK-003	Source Code	High	Repository Backup	Daily	24h	SaaS	Active
BK-004	Infrastructure Config	High	IaC Repository	Daily	24h	Git	Active

The frequency and retention values should be determined by business requirements and risk.

6. Backup Classification

Backups may be classified as:

Full Backup

A complete copy of the selected data.

Incremental Backup

Only information changed since the relevant previous backup.

Differential Backup

Information changed since the last full backup.

Snapshot

Point-in-time representation of a system, volume, or database.

Replication

Maintaining a copy of information or service data in another location or environment.

Point-in-Time Recovery

Ability to restore information to a selected point in time within the available recovery window.

The organization should select the appropriate method based on RPO, RTO, technology, risk, and cost.

7. Backup Requirements

For each critical system, define:

Requirement	Details
Information/System
Business Owner
Technical Owner
Criticality
RTO
RPO
Backup Frequency
Backup Type
Retention
Encryption
Storage Location
Secondary Copy
Immutable/Protected Copy
Restore Method
Test Frequency
Monitoring

8. RPO-Based Backup Frequency

Backup frequency should support the approved RPO.

Example:

RPO Requirement	Possible Backup Approach
Near real-time	Replication/PITR
1 hour	Hourly or continuous recovery capability
4 hours	Multiple backups per day
24 hours	Daily backup
7 days	Weekly recovery point may be sufficient

These are examples, not universal requirements.

The organization should validate that the selected backup mechanism can actually achieve the required RPO.

9. Backup Data Identification

Identify information requiring backup based on:

Business criticality
Customer importance
Regulatory requirements
Contractual requirements
Information security risk
Recovery requirements
RPO
RTO
Data loss impact

Typical critical information includes:

Customer databases
Transaction records
Customer documents
Application configuration
Source code
Infrastructure configuration
Security configuration
Critical logs
Business records

10. Backup Security

Backups should be protected through appropriate controls.

Access

Least privilege
Role-based access
MFA
Restricted administrative access
Separate backup administration where appropriate

Encryption

Protect backups using encryption appropriate to the sensitivity and risk of the information.

Integrity

Where appropriate:

Integrity checks
Checksums/hashes
Versioning
Write protection
Immutable storage

Availability

Protect backups against:

Accidental deletion
System failure
Ransomware
Unauthorized modification
Cloud account compromise

11. Backup Independence

For critical information, consider whether the backup is sufficiently independent from the production environment.

For example:

Production AWS Account

→ Production Data

→ Backup

If an attacker compromises the same administrative environment and can delete both production and backups, the backup strategy may not provide sufficient resilience.

Where justified by risk, use:

Separate accounts
Separate credentials
Restricted backup roles
Protected storage
Cross-region copies
Cross-account backup
Immutable controls
Separate administrative boundaries

The appropriate architecture depends on the organization’s risk assessment.

12. AWS SaaS Backup Example

A SaaS organization operating on AWS may protect:

RDS

Use appropriate mechanisms such as:

Automated backups
Point-in-time recovery
Snapshots
Cross-region recovery where required

S3

Use:

Versioning
Appropriate retention
Replication where required
Protected access
Encryption

Infrastructure

Use:

Infrastructure-as-code
Version-controlled configuration
Documented recovery procedures

Application

Maintain:

Trusted container images
Deployment configuration
Application configuration
Recovery artifacts

Security

Protect:

IAM configuration
KMS dependencies
Secrets
CloudTrail/security logs where required

The exact AWS configuration should be based on the organization’s architecture and recovery requirements.

13. Backup Schedule

Maintain an approved backup schedule.

System	Frequency	Backup Window	Retention	Owner
Customer DB
Customer Files
Application
Source Code
Configuration
Critical Logs

Backup schedules should consider:

System workload
Performance
Data change rate
RPO
Cost
Retention requirements
Regulatory/contractual requirements

14. Backup Execution

The backup owner or automated backup system should:

Execute backup according to the approved schedule.
Record backup status.
Validate completion.
Record failures.
Escalate critical failures.
Monitor backup storage.
Confirm retention.
Protect backup access.
Periodically verify recoverability.

Automated backups should not be considered successful solely because the scheduled job executed.

15. Backup Monitoring

Monitor:

Backup success/failure
Backup age
Backup duration
Storage capacity
Backup integrity
Replication status
Retention status
Unexpected deletion
Configuration changes
Failed restore tests

Critical backup failures should generate appropriate alerts.

16. Backup Failure Procedure

When a critical backup fails:

Step 1 — Detect

Record:

System
Backup ID
Failure time
Error
Last successful backup

Step 2 — Assess

Determine:

Current RPO exposure
Data criticality
Business impact
Security impact

Step 3 — Correct

Examples:

Retry backup.
Correct configuration.
Restore backup service.
Increase available storage.
Resolve permissions.
Contact supplier.

Step 4 — Escalate

Escalate when:

Critical data has no current backup.
RPO may be exceeded.
Multiple backup jobs fail.
Backup deletion is suspected.
Security compromise is suspected.

Step 5 — Record

Document:

Cause
Impact
Action
Resolution
Risk
Corrective action

17. Backup Retention

Retention should be defined based on:

Business requirements
Legal requirements
Regulatory requirements
Contractual commitments
Security investigation requirements
Recovery requirements
Storage cost
Data minimization requirements

There is no single universal retention period applicable to every backup.

The organization should document the reason for its retention periods.

18. Backup Retention Register

Data/System	Backup Type	Reason
Customer DB	PITR	RPO/Recovery
Customer Files	Backup	Business need
Audit Records	Backup	Compliance/assurance
Source Code	Repository	Recovery

19. Restore Request

A restore should be formally requested where appropriate.

Restore Request

Field	Details
Restore ID	RES-YYYY-XXXX
Request Date
Requestor
System/Data
Reason
Incident ID
Backup ID
Required Recovery Point
Target Environment
Data Sensitivity
Approved By
Restore Owner

20. Restore Authorization

Before restoring data, determine:

Why is restoration required?
Which backup will be used?
What recovery point is required?
Is the backup trusted?
Where will data be restored?
Who authorized the restore?
Does the restored information contain sensitive data?
Are there privacy/security considerations?
Could restoring the data overwrite valid current data?

High-risk restoration should require appropriate approval.

21. Restore Procedure

The general restore sequence is:

Restore Request

↓

Validate Authorization

↓

Identify Recovery Point

↓

Validate Backup

↓

Prepare Recovery Environment

↓

Restore Data/System

↓

Validate Integrity

↓

Validate Security

↓

Validate Application

↓

Business Validation

↓

Return to Service

↓

Record Evidence

22. Restore to Alternate Environment

Where practical, restore critical information to an isolated or controlled recovery environment before replacing production data.

This is especially important when:

Data corruption is suspected.
Ransomware is suspected.
Malware is suspected.
Unauthorized modification occurred.
Database integrity is uncertain.

The organization should avoid automatically restoring potentially compromised information directly over the production environment.

23. Database Restore

Procedure

Confirm approved restore request.
Identify backup/recovery point.
Validate backup integrity.
Prepare target database.
Restore database.
Apply required recovery point.
Validate schema.
Validate records.
Validate application connectivity.
Validate permissions.
Enable monitoring.
Perform business validation.
Record completion.

Validation

Database accessible
Expected tables available
Critical records present
Data integrity checked
Access controls correct
Encryption enabled
Application connectivity verified
Monitoring active

24. File/Object Storage Restore

For file or object storage:

Identify recovery point.
Restore required objects/files.
Validate permissions.
Validate object integrity.
Check version/history where available.
Validate encryption.
Test application access.
Record evidence.

25. Application Restore

Restore:

Application infrastructure
Configuration
Dependencies
Deployment artifacts
Secrets
Certificates
Required data

Then validate:

Application startup
Authentication
Authorization
Database connectivity
APIs
Critical workflows
Monitoring
Security controls

26. Source Code and CI/CD Restore

Critical recovery dependencies may include:

Git repository
Branches
Tags
Build configuration
Deployment scripts
Infrastructure-as-code
Container images
CI/CD configuration

Before use after a security incident:

Validate repository integrity.
Review privileged access.
Rotate compromised credentials.
Validate deployment pipelines.
Review recent changes.
Use trusted versions where necessary.

27. SaaS Backup and Restore

For critical SaaS services, determine whether the provider:

Provides backup.
Provides export capability.
Supports restoration.
Supports point-in-time recovery.
Provides retention controls.
Provides customer-managed backup options.
Has documented disaster recovery capability.

Do not assume that a SaaS provider’s availability service is equivalent to a customer-controlled backup.

For critical information, the organization should determine whether independent export or backup is necessary based on risk.

28. Security Incident Restore

For ransomware, account compromise, cloud compromise, or data corruption:

Before Restore

Confirm incident containment.
Identify compromised systems.
Identify trusted recovery point.
Preserve evidence.
Protect backups.
Validate recovery source.

During Restore

Use trusted environment.
Apply secure baseline.
Use controlled credentials.
Monitor activity.
Record actions.

After Restore

Rotate credentials where necessary.
Validate configuration.
Validate logging.
Validate monitoring.
Validate security controls.
Assess data integrity.
Monitor for recurrence.

29. Restore Validation

A successful restore should be validated at multiple levels.

Technical Validation

System available
Data accessible
Infrastructure functioning
Network functioning

Data Validation

Data complete
Data consistent
Recovery point correct
No unexpected corruption

Security Validation

Access controls correct
MFA enabled
Encryption enabled
Logging enabled
Monitoring enabled

Application Validation

Application functions
APIs work
Integrations work

Business Validation

Critical business process works
Business owner accepts recovery

30. Restore Test

Restoration should be tested periodically based on risk and criticality.

A restore test should record:

Field	Details
Test ID
System
Backup Used
Recovery Point
Test Date
Start Time
Completion Time
RTO Target
Actual Recovery Time
RPO Target
Actual Recovery Point
Data Validation
Security Validation
Business Validation
Result
Findings
Corrective Actions

31. Restore Test Results

Classify the result consistently:

Successful

Required information was restored and validated within the approved requirements.

Successful With Findings

Recovery succeeded but improvement opportunities were identified.

Partially Successful

Some recovery requirements were not achieved.

Failed

The required information or service could not be restored.

A failed restore test should generate appropriate corrective action and risk assessment.

32. RTO/RPO Validation

Backup and restore capability should be compared with approved requirements.

Requirement	Target	Actual	Result
RTO	4 hrs	3h 20m	Achieved
RPO	1 hr	45m	Achieved
Data Integrity	Required	Validated	Achieved
Security Validation	Required	Validated	Achieved

The example values above are illustrative.

33. Restore Failure

If restoration fails:

Record failure.
Preserve evidence.
Determine cause.
Assess RTO/RPO impact.
Identify alternative recovery point.
Attempt alternate recovery where authorized.
Escalate if critical.
Create corrective action.
Reassess risk.
Retest.

Possible causes include:

Corrupt backup
Incorrect recovery point
Missing dependency
Permission failure
Encryption key unavailable
Insufficient capacity
Network failure
Configuration mismatch
Incomplete backup
Human error

34. Backup Security Incident

Treat unexpected backup activity as a potential security event.

Examples:

Unexpected backup deletion
Unauthorized restore
Backup administrator compromise
Unusual backup download
Unexpected retention change
Backup encryption disabled
Backup storage made public
Recovery credentials compromised

Such events should be assessed under the organization’s Security Event and Incident Management processes.

35. Backup Access Review

Periodically review:

Backup administrators
Restore permissions
Service accounts
API access
Cloud roles
MFA
Emergency access
Backup deletion privileges

Remove unnecessary access.

Particular attention should be given to accounts that can delete both production data and backups.

36. Backup Configuration Review

Periodically verify:

Backup schedules
Retention
Encryption
Storage
Replication
Recovery points
Access control
Monitoring
Alerting
Restore capability

Configuration changes should follow the organization’s change management process.

37. Backup and Restore Metrics

Useful metrics include:

Metric	Purpose
Backup Success Rate	Measures backup reliability
Backup Failure Rate	Identifies operational gaps
Restore Success Rate	Measures recoverability
Restore Test Frequency	Measures validation
Average Restore Time	Measures recovery capability
RTO Achievement	Measures recovery performance
RPO Achievement	Measures data recovery performance
Backup Age	Identifies stale recovery points
Critical Systems With Tested Restore	Measures coverage
Open Backup Findings	Measures outstanding risk

38. Roles and Responsibilities

Role	Responsibility
Business Owner	Defines business recovery requirements
System Owner	Defines backup needs
ICT/IT Team	Operates backup systems
Cloud Team	Manages cloud backup configuration
Database Owner	Performs/validates DB restoration
Security Team	Reviews backup security
Backup Administrator	Manages backup operations
Incident Commander	Coordinates incident-related restoration
Business Validator	Confirms business recovery
Management	Approves significant risk decisions

39. Backup and Restore Records

Maintain appropriate evidence including:

Backup schedules
Backup configuration
Backup success/failure logs
Backup register
Retention records
Restore requests
Restore approvals
Restore logs
Restore test reports
RTO/RPO measurements
Security validation
Business validation
Backup access reviews
Findings
Corrective actions

40. Startup Implementation

A startup can implement a practical baseline with:

Critical Data

Identify the most important:

Customer database
Customer documents
Source code
Infrastructure configuration
Critical business records

Protection

Implement:

Automated backups
Encryption
Restricted backup access
Protected backup storage
Appropriate retention

Monitoring

Monitor:

Backup failures
Backup age
Storage capacity
Unexpected deletion

Testing

Periodically perform:

Backup → Restore → Validate → Measure → Document → Improve

The key question is:

If production disappeared today, could we actually recover our critical customer data and service?

The answer should be demonstrated through testing rather than assumption.

41. Relationship With Other ISMS Records

The Backup & Restore Procedure should connect with:

Information Classification
↓
Business Impact Assessment
↓
RTO/RPO Assessment
↓
ICT Dependency Register
↓
Backup Register
↓
Backup & Restore Procedure
↓
Disaster Recovery Runbook
↓
DR Test Report
↓
Incident Management
↓
Corrective Action Tracker
↓
Risk Reassessment
↓
ISMS Improvement Log

42. ISO/IEC 27001 Alignment

Backup and restore arrangements support the organization’s risk-based controls for:

Backup of information
ICT readiness for business continuity
Information security during disruption
Access control
Privileged access
Logging and monitoring
Cloud security
Configuration management
Supplier continuity
Incident recovery

Backup requirements should be determined based on business needs, risk, information criticality, RTO/RPO, technology architecture, and applicable legal/contractual requirements.

The organization should identify applicable controls through its risk assessment and reflect applicable controls in its Statement of Applicability.

43. Audit Evidence

An auditor should be able to trace:

Critical Information
→ Business Impact
→ RPO
→ Backup Requirement
→ Backup Configuration
→ Backup Execution
→ Protected Storage
→ Restore Test
→ Actual Recovery Point
→ Data Validation
→ Security Validation
→ Business Validation
→ Finding
→ Corrective Action

For example:

Customer Database

→ RPO 1 hour
→ PITR enabled
→ Backup successful
→ Protected recovery storage
→ Restore test performed
→ 45-minute recovery point achieved
→ Data validated
→ Security validated
→ Business owner validated
→ Evidence retained

44. Final Audit Trail

Critical Information Identified
→ Business Criticality Assessed
→ RTO/RPO Defined
→ Backup Requirement Established
→ Backup Method Selected
→ Backup Schedule Configured
→ Backup Protected
→ Backup Monitored
→ Backup Completed
→ Restore Capability Tested
→ Recovery Point Validated
→ Data Integrity Validated
→ Security Validated
→ Business Validation Completed
→ RTO/RPO Measured
→ Findings Identified
→ Corrective Actions Assigned
→ Risk Reassessed
→ Management Review

45. Final Principle

A backup is not a recovery capability until the organization has demonstrated that it can restore the required information securely, within its recovery requirements, and with sufficient evidence of integrity.

Identify + Protect + Backup + Monitor + Test + Restore + Validate + Measure + Improve.