What is ISO 27001 Annex A 8.13 – Information Backup?
ISO 27001 Annex A 8.13 focuses on ensuring that backup copies of information, software, and other information-processing resources are maintained and can be restored when needed.
Backups help an organization recover from situations such as:
- Accidental deletion
- Hardware failure
- Software failure
- Ransomware
- Malware
- Data corruption
- Database failure
- Human error
- Cyberattacks
- Cloud-service disruption
- System misconfiguration
- Operational mistakes
- Physical disasters
Simple Explanation
If important information is lost, corrupted, deleted, or unavailable, the organization should have a reliable way to recover it.
A backup is useful only if:
It exists → It is protected → It is available → It can actually be restored.
Why is Information Backup Important?
Organizations increasingly depend on digital information.
A startup may rely on:
- Customer databases
- Source code
- Cloud infrastructure
- Documents
- Contracts
- Financial records
- Employee records
- CRM
- Support tickets
- Security logs
- Configuration data
- SaaS applications
If critical information is lost, the organization may be unable to operate.
Example
Imagine a SaaS company accidentally deletes its production database.
Without a usable backup:
Database Deleted
↓
No Recovery Copy
↓
Customer Data Lost
↓
Service Disruption
↓
Business Impact
With an appropriate backup strategy:
Database Deleted
↓
Incident Detected
↓
Identify Recovery Point
↓
Restore Backup
↓
Validate Data
↓
Resume Operations
Simple Principle
A backup is not a backup strategy until you know you can restore from it.
What Does Annex A 8.13 Require?
The organization should establish and maintain appropriate backup arrangements based on:
- Business requirements
- Risk
- Information criticality
- Recovery requirements
- Legal requirements
- Regulatory requirements
- Contractual requirements
- Customer commitments
- Availability requirements
- Recovery Point Objectives (RPO)
- Recovery Time Objectives (RTO)
- Technology architecture
- Supplier/cloud dependencies
Backups should be:
- Defined
- Scheduled appropriately
- Protected
- Monitored
- Retained appropriately
- Tested
- Restorable
The exact frequency, retention, technology, and architecture should be based on organizational requirements and risk.
What is a Backup?
A backup is a separate copy of information or system data maintained so that the information can be recovered after loss, corruption, deletion, or other disruption.
Examples include:
- Database backups
- File backups
- Virtual machine backups
- Cloud snapshots
- Configuration backups
- Application backups
- SaaS backups
- Source-code repositories
- Infrastructure-as-Code repositories
- Device backups
- System images
Not every copy of information is necessarily an effective backup.
For example:
A database replica may improve availability, but it may not protect against accidental deletion if the deletion is replicated immediately.
Backup vs Replication
These are different.
| Backup | Replication |
|---|---|
| Creates recoverable historical copies | Maintains another copy/system |
| Can provide recovery from corruption/deletion | Primarily supports availability |
| Often uses retention periods | Often operates continuously |
| Can provide earlier recovery points | May replicate unwanted changes |
| Useful for disaster recovery | Useful for availability/failover |
Example:
Primary Database
↓
Replication
↓
Secondary Database
If an attacker deletes data and the deletion is replicated:
Primary Deleted
↓
Replication
↓
Secondary Deleted
A properly designed backup with historical recovery points may provide another recovery option.
Backup vs High Availability
High availability and backups solve different problems.
High Availability
Keeps services running when a component fails.
Backup
Provides a recovery copy when information or systems need to be restored.
A mature environment may need both.
What Should Be Backed Up?
The organization should identify information and systems that require recovery.
Potential examples:
Business Information
- Customer data
- Contracts
- Financial information
- HR information
- Legal records
Technical Information
- Databases
- Source code
- Configuration
- Infrastructure definitions
- Application data
- Security configurations
Operational Information
- Documentation
- Procedures
- Service configurations
- Critical logs where required
SaaS Information
Organizations should also consider data stored in third-party SaaS applications.
For example:
- CRM
- HR platform
- Accounting system
- Ticketing platform
- Collaboration platform
- Project-management system
Do not assume:
“The SaaS provider has backups, therefore we have no backup responsibility.”
The organization’s actual responsibility depends on the service, contract, architecture, recovery requirements, and provider capabilities.
Activities Required to Implement Annex A 8.13
1. Identify Critical Information
Start with the organization’s information inventory.
Identify:
- What information is critical?
- Where is it stored?
- Who owns it?
- How quickly must it be recovered?
- How much data loss is acceptable?
This connects with A.5.9 – Inventory of Information and Other Associated Assets.
2. Identify Critical Systems
Create a system list.
Example:
| System | Information | Criticality |
|---|---|---|
| Production Database | Customer data | Critical |
| GitHub | Source code | Critical |
| CRM | Customer/sales data | High |
| Accounting | Financial records | High |
| HR Platform | Employee data | High |
| Google Workspace | Business documents/email | High |
| Development Environment | Test data | Medium |
3. Define Recovery Requirements
Two important concepts are:
Recovery Point Objective – RPO
RPO describes the maximum acceptable amount of data loss measured in time.
Example:
RPO = 4 hours
This means the organization aims to recover data to a point no more than approximately four hours before the disruption, subject to the actual backup architecture and circumstances.
Recovery Time Objective – RTO
RTO describes the target time within which a system or service should be restored after disruption.
Example:
RTO = 8 hours
This means the organization targets restoring the service within eight hours.
RPO and RTO should be based on business impact and risk rather than arbitrary numbers.
4. Define Backup Frequency
Backup frequency should reflect:
- RPO
- Information criticality
- Data-change frequency
- Business impact
- Recovery requirements
- Storage costs
- Technology capabilities
Example:
| System | Example Backup Frequency |
|---|---|
| Critical production database | Frequent/continuous according to RPO |
| Customer files | Daily or as required |
| Configuration | On change + scheduled |
| Source code | Version-controlled continuously |
| Financial records | Daily or as required |
| Archives | Based on retention requirements |
These are examples, not ISO 27001-prescribed frequencies.
5. Define Backup Retention
Determine how long backups should be retained.
Consider:
- Business requirements
- RPO/RTO
- Legal requirements
- Regulatory requirements
- Customer contracts
- Storage capacity
- Security risks
- Data-retention requirements
Example:
Daily Backups → 30 Days
Weekly Backups → 12 Weeks
Monthly Backups → 12 Months
Actual retention should be based on the organization’s requirements.
6. Protect Backup Information
Backups contain potentially sensitive information.
Therefore, protect them appropriately.
Controls may include:
- Encryption
- Access restrictions
- MFA
- Separate administrative access
- Secure storage
- Network restrictions
- Monitoring
- Immutable storage where appropriate
- Offline copies where justified
- Backup-account protection
Important Principle
If the production data is sensitive, assume the backup is sensitive too.
7. Separate Backup Access From Normal Access
A compromised administrator account should not automatically provide unrestricted access to every backup.
Consider:
- Separate backup administration
- Least privilege
- MFA
- Role-based access
- Privileged access management
- Restricted backup deletion rights
- Monitoring
This is particularly important for ransomware scenarios.
8. Protect Backups Against Ransomware
A common ransomware scenario is:
Attacker
↓
Compromise Admin Account
↓
Encrypt Production
↓
Access Backup System
↓
Delete/Encrypt Backups
↓
Recovery Becomes Difficult
Therefore, organizations should consider controls such as:
- Immutable backups
- Object lock
- Restricted deletion permissions
- Separate backup credentials
- MFA
- Offline copies where justified
- Separate backup environments
- Monitoring
- Backup integrity testing
Not every startup needs every control. The appropriate architecture depends on risk.
9. Monitor Backup Jobs
A backup system should not simply be configured and forgotten.
Monitor:
- Successful backups
- Failed backups
- Missed backups
- Storage capacity
- Backup age
- Backup integrity
- Encryption status
- Unauthorized changes
- Retention failures
Example
Backup Job
↓
Success?
┌──┴──┐
Yes No
↓ ↓
Record Alert
↓
Investigate
↓
Correct
10. Test Restoration
This is one of the most important parts of A.8.13.
A successful backup job does not necessarily mean the data can be restored.
Test:
- File restoration
- Database restoration
- Application restoration
- Configuration restoration
- Full-system recovery where required
Example
Backup Exists
↓
Restore Test
↓
Data Available?
↓
Application Works?
↓
Data Integrity Verified?
↓
Recovery Time Acceptable?
Document the results.
11. Validate Backup Integrity
Where appropriate, verify that backups are:
- Complete
- Accessible
- Uncorrupted
- Consistent
- Within retention
- Protected
- Restorable
For databases, this may include database-integrity or application-level validation.
12. Secure Backup Credentials
Backup credentials can be extremely powerful.
Protect:
- Backup administrator accounts
- API keys
- Service accounts
- Encryption keys
- Recovery credentials
Do not store them casually in:
- Source code
- Shared spreadsheets
- Chat messages
- Personal password managers
- Uncontrolled documents
Startup Example
Example: 40-Person SaaS Company
The startup operates a SaaS application using:
- AWS
- PostgreSQL
- Object storage
- GitHub
- CI/CD
- Google Workspace
- CRM
- Accounting platform
Poor Backup Model
The company says:
“AWS handles backups.”
But there is no documented:
- Backup scope
- Retention
- Recovery requirement
- Backup monitoring
- Restoration test
- Ownership
- Evidence
Better Model
Critical Systems Identified
↓
Recovery Requirements Defined
↓
Backup Strategy Defined
↓
Automated Backups
↓
Backup Monitoring
↓
Backup Protection
↓
Periodic Restore Test
↓
Results Recorded
↓
Management Review
Example Startup Backup Register
| System | Data | RPO | RTO | Backup | Retention | Owner |
|---|---|---|---|---|---|---|
| Production DB | Customer data | 1 hr | 4 hrs | Automated | 30 days | Engineering |
| Object Storage | Customer files | 4 hrs | 8 hrs | Automated | 60 days | Engineering |
| GitHub | Source code | 24 hrs* | 8 hrs | Repository + backup | 90 days | CTO |
| Accounting | Financial data | 24 hrs | 24 hrs | Provider/export | 7 years* | Finance |
| Google Workspace | Business data | 24 hrs | 24 hrs | Approved backup method | As required | IT |
*Actual RPO/RTO and retention should be defined according to the organization’s requirements and applicable obligations.
Backup Risk Assessment
| Scenario | Impact | Example Treatment |
|---|---|---|
| Production DB failure | High | Automated backup + restore testing |
| Ransomware | Critical | Isolated/immutable backup |
| Accidental deletion | High | Point-in-time recovery |
| Cloud-region disruption | High | Recovery architecture |
| Backup job failure | High | Automated monitoring |
| Backup credentials compromised | Critical | MFA + restricted privileges |
| Backup storage full | High | Capacity monitoring |
| Corrupt backup | High | Restore/integrity testing |
Backup Strategy for SaaS Startups
A startup should consider at least these categories:
1. Production Database
Usually one of the highest-priority assets.
Consider:
- Automated backups
- Point-in-time recovery
- Retention
- Restore testing
2. Customer Files
Consider:
- Versioning
- Backup
- Retention
- Recovery testing
3. Source Code
Use:
- Version control
- Repository protection
- Appropriate backup/recovery arrangements
4. Infrastructure Configuration
Back up or version:
- Infrastructure-as-Code
- Configuration
- Network configuration
- Security configuration
5. Business SaaS Data
Evaluate important SaaS systems individually.
Backup and Cloud Services
Cloud platforms can make backup implementation easier, but they do not eliminate the organization’s responsibility to understand its recovery requirements.
For each cloud service, ask:
- What is automatically backed up?
- What is not backed up?
- How long is it retained?
- Can the backup be deleted by an administrator?
- Can data be restored?
- How quickly?
- Where is the backup stored?
- Is it encrypted?
- Who can access it?
- Has restoration been tested?
Backup and Third-Party SaaS
A company may assume that SaaS vendors protect everything.
However, the organization should determine:
- What the supplier backs up
- What recovery capability exists
- What retention applies
- Whether deleted data can be recovered
- What contractual commitments exist
- Whether customer-controlled exports are required
- Whether independent backup is justified
This should connect with supplier-management controls such as:
- A.5.19
- A.5.20
- A.5.21
- A.5.22
Backup and Business Continuity
A.8.13 should connect with business continuity.
Example:
System Failure
↓
Incident Response
↓
Determine Business Impact
↓
Activate Recovery Procedure
↓
Restore Information
↓
Validate Systems
↓
Resume Operations
Related controls include:
- A.5.29 – Information Security During Disruption
- A.5.30 – ICT Readiness for Business Continuity
- A.8.14 – Redundancy of Information Processing Facilities
Backup vs Redundancy
These controls should not be confused.
Backup
Provides recoverable information.
Redundancy
Provides alternative processing capability.
Example:
Backup:
Production Data
↓
Recovery Copy
versus:
Redundancy:
Primary System
↓
Secondary System
↓
Failover
A system can have redundancy but still need backups.
Backup and Data Deletion
A.8.10 – Information Deletion should also be considered.
Deleting information from production does not necessarily mean it immediately disappears from every backup.
Organizations should define:
- Backup retention
- Deletion handling
- Legal holds
- Restoration behavior
- Expiry of backup copies
Example:
Production Data Deleted
↓
Backup Still Exists
↓
Backup Retention Period
↓
Backup Expires
↓
Information No Longer Recoverable
The exact process depends on the organization’s architecture and applicable requirements.
Audit Evidence for Annex A 8.13
An auditor may request:
Governance
- Backup Policy
- Backup Procedure
- Business Continuity Policy
- Disaster Recovery Plan
- Backup Standard
Planning
- Backup inventory
- System criticality assessment
- RPO/RTO definitions
- Backup requirements
- Retention schedule
Technical Evidence
- Backup configuration
- Backup schedules
- Backup dashboards
- Backup reports
- Storage configuration
- Encryption configuration
- Access-control configuration
Operational Evidence
- Successful backup logs
- Failed-backup alerts
- Backup monitoring reports
- Restore test results
- Recovery exercise reports
- Corrective actions
Supplier Evidence
- Cloud-provider backup documentation
- SaaS provider assurance
- Contracts/SLA
- Supplier recovery commitments
ISO 27001 Annex A 8.13 Audit Checklist
| Question | Yes/No | Evidence |
|---|---|---|
| Are critical information assets identified? | Asset inventory | |
| Are critical systems identified? | System register | |
| Are backup requirements defined? | Backup policy | |
| Are RPOs defined where appropriate? | Recovery requirements | |
| Are RTOs defined where appropriate? | BCP/DR | |
| Are backups performed according to requirements? | Backup reports | |
| Are backups protected? | Configuration | |
| Are backups encrypted where appropriate? | Encryption evidence | |
| Is backup access restricted? | Access matrix | |
| Are backup failures monitored? | Alerts/logs | |
| Is backup capacity monitored? | Capacity reports | |
| Are backups protected from unauthorized deletion? | Access/configuration | |
| Are restoration tests performed? | Restore reports | |
| Are restore results documented? | Test records | |
| Are backup retention periods defined? | Retention schedule | |
| Are third-party backups evaluated? | Supplier assessment | |
| Are backup controls reviewed periodically? | Review records |
Common Mistakes
1. “We Have Cloud Backups”
Simply having a cloud service does not demonstrate that the organization’s recovery requirements are met.
2. Never Testing Restoration
This is one of the biggest weaknesses.
A backup can fail because of:
- Corruption
- Incorrect configuration
- Missing dependencies
- Expired retention
- Encryption-key problems
- Permission problems
- Incomplete data
3. Backing Up Everything Without Prioritization
Backup strategy should be based on information criticality and recovery requirements.
4. Backup Administrator Has Too Much Access
If the same account can:
- Create backups
- Delete backups
- Change retention
- Disable backups
then compromise of that account can significantly increase recovery risk.
5. Ignoring Backup Failures
A backup system can silently fail.
Monitoring and alerting are important.
6. Treating Replication as Backup
Replication may replicate corruption or deletion.
7. Ignoring SaaS Data
Critical business information can exist outside the organization’s primary infrastructure.
8. No Backup Retention Strategy
Keeping backups forever may create:
- Cost
- Privacy risk
- Compliance risk
- Security exposure
9. No Recovery Documentation
Employees should know:
- What to restore
- From where
- Who approves recovery
- Who performs recovery
- How recovery is validated
10. Backup Credentials Are Not Protected
Backup systems are high-value targets.
Practical Startup Implementation Model
A startup can implement A.8.13 using:
Identify → Classify → Define → Backup → Protect → Monitor → Test → Restore → Review
Identify
Identify critical systems and information.
Classify
Determine business and information criticality.
Define
Define RPO, RTO, frequency, retention, ownership.
Backup
Implement appropriate automated backup mechanisms.
Protect
Secure backup data and credentials.
Monitor
Monitor successful and failed backups.
Test
Perform restoration tests.
Restore
Demonstrate that recovery actually works.
Review
Improve the backup strategy based on test results, incidents, changes, and business growth.
Minimum Viable Backup Strategy for a Startup
A startup does not necessarily need a highly complex disaster-recovery architecture.
A practical starting point can include:
Critical Database
- Automated backups
- Appropriate retention
- Encryption
- Restricted access
- Restore testing
Source Code
- Version control
- Protected repositories
- Recovery strategy
Customer Files
- Backup/versioning
- Appropriate retention
- Recovery testing
Business Documents
- Approved storage
- Backup/recovery mechanism where required
SaaS Applications
- Identify critical SaaS data
- Understand provider recovery capabilities
- Determine whether independent backup is necessary
Monitoring
- Backup failure alerts
- Storage alerts
- Periodic review
Testing
- Scheduled restore tests
- Documented results
- Corrective actions
Policy vs. Process vs. Evidence
| Layer | Example |
|---|---|
| Policy | Critical information shall be backed up according to defined requirements |
| Process | Backup jobs run according to documented schedules |
| Technical Control | Automated database backup |
| Evidence | Backup logs and restore-test results |
| Review | Periodic backup and recovery review |
A mature implementation connects all these layers.
Relationship With Other ISO 27001 Controls
A.5.9 – Inventory of Information and Other Associated Assets
Helps identify what needs protection and recovery.
A.5.29 – Information Security During Disruption
Addresses security during disruption.
A.5.30 – ICT Readiness for Business Continuity
Addresses ICT readiness for continuity.
A.7.10 – Storage Media
Relevant when physical/removable storage is used for backups.
A.7.11 – Supporting Utilities
Relevant to availability of supporting infrastructure.
A.7.13 – Equipment Maintenance
Helps maintain equipment supporting backup operations.
A.8.6 – Capacity Management
Backup storage capacity must be managed.
A.8.9 – Configuration Management
Backup configurations should be controlled.
A.8.10 – Information Deletion
Backup retention and deletion should be considered.
A.8.12 – Data Leakage Prevention
Backup information should be protected from unauthorized disclosure.
A.8.14 – Redundancy of Information Processing Facilities
Addresses alternative processing capability.
A.8.15 – Logging
Backup and recovery activities may require logging.
A.8.13 vs A.8.14
| Control | Main Focus |
|---|---|
| A.8.13 Information Backup | Can we recover information? |
| A.8.14 Redundancy of Information Processing Facilities | Can we continue processing using alternative facilities/components? |
Example:
Backup: Restore yesterday’s database.
Redundancy: Fail over to a secondary system when the primary system fails.
They can work together.
Questions an Auditor May Ask
1. What information is backed up?
Show your backup inventory.
2. Why did you choose this backup frequency?
Explain the risk and recovery requirements.
3. What are your RPO and RTO?
Show documented business/recovery requirements.
4. How do you know backups are successful?
Show monitoring and backup reports.
5. Who can delete backups?
Show access controls.
6. Are backups encrypted?
Demonstrate the configuration.
7. What happens if ransomware attacks the production environment?
Explain the recovery architecture.
8. Have you tested restoration?
Show the latest restore-test evidence.
9. What happens when a backup job fails?
Show alerting and incident/remediation records.
10. How do you protect backup credentials?
Show privileged-access controls.
11. What SaaS platforms contain critical business information?
Show the SaaS/data inventory.
12. Does your cloud provider’s backup satisfy your requirements?
Show the supplier assessment and documented recovery requirements.
13. How long are backups retained?
Show the retention schedule.
14. How do you handle backup data when information must be deleted?
Show the relationship between retention, deletion, and backup lifecycle.
Useful Resources
Organizations implementing Annex A 8.13 may maintain:
- Information Backup Policy – [Insert Draft Document Link]
- Backup and Recovery Procedure – [Insert Draft Document Link]
- Backup Inventory – [Insert Draft Document Link]
- Backup Requirements Register – [Insert Draft Document Link]
- RPO/RTO Assessment – [Insert Draft Document Link]
- Backup Retention Schedule – [Insert Draft Document Link]
- Backup Monitoring Checklist – [Insert Draft Document Link]
- Backup Access Control Matrix – [Insert Draft Document Link]
- Backup Restore Test Procedure – [Insert Draft Document Link]
- Backup Restore Test Report – [Insert Draft Document Link]
- Backup Failure Incident Procedure – [Insert Draft Document Link]
- SaaS Backup Assessment Checklist – [Insert Draft Document Link]
- Disaster Recovery Plan – [Insert Draft Document Link]
- Backup Audit Checklist – [Insert Draft Document Link]
Startup-Focused Quick Summary
For a startup, A.8.13 can be reduced to seven practical questions:
1. What information cannot afford to be lost?
Identify critical information.
2. Where is it stored?
Database, cloud storage, SaaS platforms, repositories, etc.
3. How much data can we afford to lose?
Define the appropriate RPO.
4. How quickly do we need to recover?
Define the appropriate RTO.
5. How often should we back it up?
Based on business and risk requirements.
6. Can an attacker delete our backups?
Protect backup systems with appropriate access controls and, where justified, isolation or immutability.
7. Have we actually restored from the backup?
Test it.
Startup-Focused Final Takeaway
A backup strategy is not simply:
“We use AWS, so our data is backed up.”
A real ISO 27001 backup control should answer:
What → Where → How Often → How Long → Who → How Protected → How Monitored → How Restored
The most important distinction is:
Backup success is not the same as recovery success.
A startup should periodically prove that critical information can actually be restored.
Simple Startup Model
Identify → Define RPO/RTO → Backup → Protect → Monitor → Test → Restore → Improve
For a SaaS company, pay particular attention to:
Production databases + customer files + source code + infrastructure configuration + critical SaaS data + backup credentials.
One-Line Summary
ISO 27001 Annex A 8.13 ensures that appropriate backup arrangements are established, protected, monitored, and tested so that critical information and information-processing resources can be recovered when required.