What is ISO 27001 Annex A 8.14 – Redundancy of Information Processing Facilities?
ISO 27001 Annex A 8.14 focuses on ensuring that information-processing facilities have sufficient redundancy to meet availability requirements.
The objective is to reduce the risk that a failure of a single system, component, facility, or service causes unacceptable disruption to business operations.
Redundancy may involve:
- Multiple servers
- Multiple database instances
- Secondary network connections
- Redundant firewalls
- Multiple availability zones
- Secondary cloud infrastructure
- Backup power
- Redundant storage
- High-availability systems
- Failover systems
- Alternative processing facilities
- Multiple communication links
- Geographically separated infrastructure
Simple Explanation
If one critical component fails, there should be an appropriate alternative so the business can continue operating or recover within its required timeframe.
Why is Redundancy Important?
Modern businesses depend heavily on information-processing systems.
A single point of failure can cause:
- Application downtime
- Customer service interruption
- Revenue loss
- Loss of productivity
- Missed transactions
- SLA violations
- Security-monitoring gaps
- Operational disruption
- Customer dissatisfaction
Example
Suppose a SaaS company operates its entire application on one server.
Customer
↓
Single Server
↓
Server Failure
↓
Application Unavailable
With appropriate redundancy:
┌── Primary Server
Customer ────┤
└── Secondary Server
↓
Failover
↓
Service Continues
Simple Principle
Critical services should not depend unnecessarily on one component that can fail.
What Does Annex A 8.14 Require?
The organization should determine whether redundancy is necessary based on:
- Business continuity requirements
- Availability requirements
- Risk assessment
- System criticality
- Recovery requirements
- Customer commitments
- Service-level agreements
- Regulatory requirements
- Technology architecture
- Single points of failure
- Cost and practicality
Where redundancy is required, it should be appropriately implemented and tested.
ISO 27001 does not require every system to have duplicate infrastructure.
A low-risk internal system may not require redundancy.
A critical customer-facing service may require significant redundancy.
What is Redundancy?
Redundancy means having an alternative component, system, facility, or capability available to reduce the impact of failure.
Examples:
Server Redundancy
Server A
↓
Failure
↓
Server B
Network Redundancy
Internet Provider A
↓
Router
↓
Internet Provider B
Database Redundancy
Primary Database
↓
Secondary Database
↓
Failover
Cloud Redundancy
Availability Zone A
↓
Application
↓
Availability Zone B
Redundancy vs Backup
These controls are often confused.
| Redundancy | Backup |
|---|---|
| Supports continued availability or failover | Supports recovery of information |
| Often operates in real time | Usually provides historical recovery points |
| Reduces impact of component failure | Helps recover lost/corrupted/deleted information |
| May automatically fail over | Usually requires restoration |
| Does not necessarily protect against logical deletion | Can provide recovery from earlier state |
Example
Redundancy:
Primary database fails → secondary database takes over.
Backup:
Database is corrupted → restore an earlier valid copy.
Important
Redundancy does not replace backup.
A replicated database can replicate corrupted or maliciously deleted data.
Redundancy vs Disaster Recovery
Redundancy
Provides an alternative processing capability.
Disaster Recovery
Provides a broader recovery strategy following major disruption.
Example:
Component Failure
↓
Redundancy / Failover
↓
Service Continues
versus:
Major Disaster
↓
Disaster Recovery Plan
↓
Alternative Environment
↓
Restore Systems/Data
↓
Resume Operations
Redundancy can be one part of a broader business-continuity and disaster-recovery strategy.
What are Single Points of Failure?
A Single Point of Failure (SPOF) is a component whose failure can cause unacceptable disruption because there is no suitable alternative.
Examples:
- One internet connection
- One firewall
- One critical server
- One database instance
- One power supply
- One DNS provider
- One authentication dependency
- One cloud region
- One key administrator
- One critical third-party service
Example
Internet
↓
Single ISP
↓
Firewall
↓
Application
If the ISP fails:
ISP Failure
↓
No Internet
↓
Business Disruption
A second connectivity provider may reduce this risk where justified.
Activities Required to Implement Annex A 8.14
1. Identify Critical Information-Processing Facilities
Start with the asset and system inventory.
Identify:
- Production systems
- Databases
- Network infrastructure
- Cloud infrastructure
- Storage
- Authentication systems
- Security infrastructure
- Communication systems
- Critical SaaS platforms
This connects with A.5.9 – Inventory of Information and Other Associated Assets.
2. Identify Critical Business Services
Do not begin by buying duplicate technology.
Start with the business.
Ask:
- Which services are critical?
- How long can they be unavailable?
- Which systems support those services?
- What happens if each component fails?
Example:
| Business Service | Criticality |
|---|---|
| Customer SaaS platform | Critical |
| Customer support | High |
| Payment processing | Critical |
| Internal HR system | Medium |
| Marketing website | Medium |
| Internal test environment | Low |
3. Map Dependencies
A service may depend on multiple components.
Example:
Customer Application
↓
Load Balancer
↓
Application Servers
↓
Database
↓
Storage
↓
Network
↓
Cloud Provider
Also consider:
- DNS
- Identity provider
- Payment gateway
- CDN
- Monitoring
- Third-party APIs
A system is only as resilient as its important dependencies.
4. Identify Single Points of Failure
Create a simple SPOF assessment.
| Component | Failure Impact | Redundant? | Action |
|---|---|---|---|
| Production DB | Critical | Yes | Maintain |
| Internet | High | No | Evaluate second ISP |
| Firewall | High | No | Evaluate HA |
| Development server | Low | No | Risk accepted |
| DNS | High | Yes/Provider | Monitor |
Not every SPOF must automatically be eliminated.
The organization should assess and treat it according to risk.
5. Define Availability Requirements
Determine the availability requirements for critical services.
Consider:
- Business impact
- Customer expectations
- SLA commitments
- Regulatory requirements
- RTO
- Operational requirements
Example:
Customer-facing SaaS application must support defined availability requirements.
The required redundancy should follow from these requirements.
6. Design Appropriate Redundancy
Potential options include:
Infrastructure
- Multiple servers
- Multiple storage devices
- Redundant power
- Redundant network equipment
Cloud
- Multiple availability zones
- Multi-region architecture where justified
- Load balancing
- Auto scaling
- Managed failover
Connectivity
- Multiple ISPs
- Secondary network path
- Backup communication
Security
- High-availability firewalls
- Redundant security appliances
- Alternative authentication mechanisms where appropriate
7. Consider Geographical Redundancy
For critical services, geographic separation may be appropriate.
Example:
Region A
↓
Primary Service
↓
Region B
↓
Recovery / Failover
However, multi-region architecture can significantly increase:
- Cost
- Complexity
- Operational requirements
- Testing requirements
It should therefore be justified by business and risk requirements.
8. Protect Redundant Components
A redundant component should not introduce another security weakness.
For example:
- Protect administrative access
- Apply secure configurations
- Patch systems
- Monitor components
- Restrict access
- Protect credentials
- Review configurations
Redundancy should be integrated with other security controls.
9. Monitor Failover Components
Organizations should know whether redundant systems are actually available.
Monitor:
- Health status
- Synchronization
- Replication
- Connectivity
- Storage
- Capacity
- Failover readiness
- Configuration differences
A secondary system that has silently failed is not effective redundancy.
10. Test Failover
This is critical.
A company should not assume:
“We have a secondary system, so failover will work.”
Test where appropriate.
Example:
Primary System
↓
Controlled Failure
↓
Failover
↓
Secondary System
↓
Validate Service
↓
Record Results
Document:
- Test date
- Scenario
- Systems tested
- Expected result
- Actual result
- Downtime
- Issues
- Corrective actions
Startup Example
Example: 50-Person SaaS Startup
The startup runs its customer application in the cloud.
Initial Architecture
Users
↓
Load Balancer
↓
One Application Instance
↓
One Database
The company discovers:
- One application instance
- One database instance
- One internet connection for office operations
- No tested failover
The organization assesses the business impact.
Improved Architecture
┌── App Instance A
Users → Load Balancer┤
└── App Instance B
↓
Database Cluster
↓
Backup / Recovery
The architecture may also use cloud availability zones where justified.
The exact architecture should depend on:
- Customer requirements
- Availability requirements
- Risk
- Budget
- Technical design
Startup Example: Office Internet
A startup has a cloud-hosted SaaS platform but depends on internet connectivity for employees.
Risk
ISP Failure
↓
Employees Cannot Access Cloud Services
↓
Business Productivity Disrupted
Possible treatment:
- Secondary ISP
- 4G/5G backup
- Alternate working location
- Remote-work capability
The appropriate option depends on the organization’s requirements.
Redundancy Assessment
A simple assessment can be maintained:
| Service | Component | Failure Scenario | Impact | Redundancy Required? | Treatment |
|---|---|---|---|---|---|
| SaaS Application | App Server | Server failure | High | Yes | Multiple instances |
| SaaS Application | Database | DB failure | Critical | Yes | HA/replication |
| Office | ISP | Internet outage | Medium | Maybe | Secondary ISP |
| HR | HR SaaS | Provider outage | Medium | Depends | Supplier/continuity plan |
| Marketing | Website | Hosting failure | Low | Maybe | Risk-based |
Redundancy and Cloud Computing
Cloud environments provide many options for redundancy.
Examples:
- Availability zones
- Load balancing
- Auto scaling
- Database replicas
- Multi-region deployments
- Managed failover
- Multiple network paths
But:
Cloud does not automatically mean redundant.
A company can still create a single point of failure in the cloud.
Example:
Cloud Provider
↓
One Region
↓
One VM
↓
One Database
Being “in the cloud” does not automatically remove the risk.
Cloud Redundancy Assessment
For critical systems, consider:
| Question | Example |
|---|---|
| Is the application deployed across multiple instances? | Yes |
| Are critical components in multiple availability zones? | Where required |
| Is the database redundant? | As required |
| Is failover automated? | Where appropriate |
| Is failover tested? | Periodically |
| Are backups separate from redundancy? | Yes |
| Are cloud dependencies identified? | Yes |
| Are regional failures considered? | Risk-based |
Third-Party and SaaS Redundancy
A company may depend on suppliers for critical services.
Examples:
- Cloud provider
- Identity provider
- Payment provider
- DNS provider
- Email provider
- CRM
- Security platform
- Communication platform
Assess:
- Supplier availability commitments
- SLA
- Redundancy
- Disaster recovery
- Service dependencies
- Alternative providers
- Exit strategy where appropriate
This connects with:
- A.5.19 Supplier Relationships
- A.5.20 Supplier Agreements
- A.5.21 ICT Supply Chain
- A.5.22 Monitoring Supplier Services
Redundancy and Authentication
Authentication can become a hidden single point of failure.
Example:
All Employees
↓
Single Identity Provider
↓
Provider Outage
↓
Employees Cannot Access Critical Systems
Depending on business requirements, organizations should consider:
- Provider availability
- Emergency access
- Recovery procedures
- Break-glass accounts
- Alternative authentication mechanisms
Any emergency access should itself be strongly controlled and monitored.
Redundancy and Security Monitoring
Security systems can also have availability requirements.
Consider:
- SIEM
- Logging
- EDR
- Network monitoring
- Identity monitoring
- Backup monitoring
- Alerting
If a critical monitoring platform fails, the organization may lose visibility into security events.
Redundancy and Business Continuity
A.8.14 should be connected with business continuity.
Example:
Business Service
↓
Critical Systems
↓
Dependency Analysis
↓
Failure Scenarios
↓
Redundancy Requirements
↓
Failover Design
↓
Testing
↓
Business Continuity
Relevant controls include:
- A.5.29 – Information Security During Disruption
- A.5.30 – ICT Readiness for Business Continuity
- A.8.13 – Information Backup
- A.8.14 – Redundancy
Audit Evidence for Annex A 8.14
An auditor may request:
Governance
- Business Continuity Policy
- ICT Continuity Policy
- Availability Requirements
- Redundancy Policy
- Disaster Recovery Plan
Planning
- Critical system inventory
- Business impact assessment
- Dependency mapping
- SPOF assessment
- Risk assessments
Technical Evidence
- Architecture diagrams
- High-availability configurations
- Cloud architecture
- Load-balancer configuration
- Database replication
- Network redundancy
- Secondary ISP configuration
Monitoring
- System health reports
- Replication status
- Monitoring dashboards
- Failover alerts
Testing
- Failover test reports
- Disaster recovery test
- Recovery exercise
- Corrective-action records
Supplier Evidence
- Cloud provider availability documentation
- SLA
- Supplier continuity information
- Critical supplier assessments
ISO 27001 Annex A 8.14 Audit Checklist
| Question | Yes/No | Evidence |
|---|---|---|
| Are critical information-processing facilities identified? | Asset register | |
| Are critical business services identified? | BIA | |
| Are availability requirements defined? | Requirements | |
| Are system dependencies documented? | Architecture | |
| Are single points of failure identified? | SPOF assessment | |
| Are redundancy requirements risk-based? | Risk assessment | |
| Is redundancy implemented where required? | Technical evidence | |
| Are redundant systems appropriately secured? | Configuration | |
| Are redundant systems monitored? | Monitoring reports | |
| Is replication monitored where applicable? | Replication logs | |
| Is failover tested? | Test reports | |
| Are failover issues tracked? | Corrective actions | |
| Are cloud dependencies assessed? | Supplier assessment | |
| Are critical SaaS dependencies considered? | Supplier register | |
| Are redundancy arrangements reviewed periodically? | Review records |
Common Mistakes
1. Assuming Cloud Automatically Means Redundancy
A cloud deployment can still contain multiple single points of failure.
2. Confusing Backup With Redundancy
A backup helps recover information.
Redundancy helps maintain or quickly restore processing capability.
You may need both.
3. Building Redundancy Without Business Justification
Not every system needs a duplicate environment.
Controls should be proportional to risk and availability requirements.
4. Never Testing Failover
A secondary system that has never been tested may not work when needed.
5. Ignoring Dependencies
The application may be redundant while:
- DNS
- Identity
- Payment
- Network
- Storage
- Third-party APIs
remain single points of failure.
6. Ignoring Configuration Differences
Primary and secondary systems can drift apart.
This connects with A.8.9 – Configuration Management.
7. No Monitoring
A failed secondary system can remain unnoticed.
8. Overengineering
Multi-region infrastructure, multiple providers, and complex failover architectures can create unnecessary cost and complexity for a small organization.
9. Ignoring SaaS Dependencies
A startup may have a highly redundant application but depend on one external service that can stop the business.
10. No Evidence of Testing
Saying:
“We have failover.”
is weaker than showing:
“We tested failover on this date, identified this issue, corrected it, and retested.”
Practical Startup Implementation Model
Use this lifecycle:
Identify → Assess → Map → Find SPOFs → Define Requirements → Implement → Monitor → Test → Improve
Identify
Identify critical systems and services.
Assess
Determine the impact of failure.
Map
Understand technical and supplier dependencies.
Find SPOFs
Identify components that could cause unacceptable disruption.
Define Requirements
Determine where redundancy is actually necessary.
Implement
Deploy appropriate redundancy.
Monitor
Ensure redundant components remain healthy.
Test
Test failover and recovery.
Improve
Address weaknesses and changing business requirements.
Minimum Viable Redundancy for a Startup
A startup does not necessarily need a multi-region architecture.
Start with the most important failure scenarios.
Production Application
Consider:
- Multiple application instances
- Load balancing
- Health checks
Database
Consider:
- High availability where required
- Replication
- Automated recovery
Backup
Maintain:
- Separate backup strategy
- Appropriate retention
- Restore testing
Connectivity
Consider:
- Secondary internet connection
- Mobile backup
- Remote-work capability
Critical SaaS
Evaluate:
- Supplier availability
- Recovery capability
- Business impact
Critical Security Systems
Consider availability of:
- Identity
- Monitoring
- Endpoint security
- Backup systems
Policy vs. Process vs. Evidence
| Layer | Example |
|---|---|
| Policy | Critical information-processing facilities shall have redundancy appropriate to business and security requirements |
| Process | Critical systems are assessed for availability and single points of failure |
| Technical Control | Multi-instance application deployment |
| Evidence | Architecture diagrams, failover logs, test reports |
| Review | Periodic redundancy and availability review |
Relationship With Other ISO 27001 Controls
A.5.9 – Inventory of Assets
Identifies critical systems and infrastructure.
A.5.29 – Information Security During Disruption
Addresses security during disruptive events.
A.5.30 – ICT Readiness for Business Continuity
Connects ICT capabilities with business continuity.
A.5.37 – Documented Operating Procedures
Supports failover and recovery procedures.
A.7.11 – Supporting Utilities
Addresses utilities such as power and cooling.
A.8.6 – Capacity Management
Ensures redundant infrastructure has adequate capacity.
A.8.9 – Configuration Management
Helps keep primary and redundant systems appropriately configured.
A.8.13 – Information Backup
Provides recoverable copies of information.
A.8.14 – Redundancy
Provides alternative processing capability.
A.8.20 – Network Security
Relevant to redundant network infrastructure.
A.8.21 – Security of Network Services
Relevant to availability and security requirements for network services.
A.8.32 – Change Management
Helps ensure changes do not unintentionally break redundancy or failover.
A.8.13 vs A.8.14
| A.8.13 Backup | A.8.14 Redundancy | |
|---|---|---|
| Main objective | Recover information | Maintain processing availability |
| Typical mechanism | Backup | Failover/HA |
| Historical recovery | Yes | Usually not |
| Immediate failover | Usually no | Often |
| Protects against deletion | Potentially | Not necessarily |
| Protects against component failure | Indirectly | Directly |
Simple Example
Server fails → secondary server takes over
A.8.14
Database is corrupted → restore previous backup
A.8.13
Questions an Auditor May Ask
1. Which systems are considered critical?
Show the system inventory and business-impact assessment.
2. What happens if your primary production system fails?
Explain the failover architecture.
3. What are your single points of failure?
Show the SPOF assessment.
4. Why did you decide redundancy was necessary for this system?
Show the risk and availability assessment.
5. How do you test failover?
Show test records.
6. When was the last failover test?
Provide the latest documented evidence.
7. How do you know the secondary system is working?
Show monitoring.
8. Are your cloud systems redundant?
Demonstrate the actual architecture rather than simply stating that the system is cloud-hosted.
9. What happens if a critical third-party provider becomes unavailable?
Show supplier and business-continuity assessments.
10. Is your backup strategy separate from your redundancy strategy?
Demonstrate both.
11. What happens if your identity provider fails?
Explain the recovery/emergency-access approach.
12. How do you prevent configuration drift between primary and redundant systems?
Show configuration management controls.
Useful Resources
Organizations implementing Annex A 8.14 may maintain:
- Redundancy and Availability Policy – [Insert Draft Document Link]
- ICT Business Continuity Policy – [Insert Draft Document Link]
- Critical Systems Register – [Insert Draft Document Link]
- System Dependency Register – [Insert Draft Document Link]
- Single Point of Failure Assessment – [Insert Draft Document Link]
- Redundancy Risk Assessment – [Insert Draft Document Link]
- High Availability Architecture Document – [Insert Draft Document Link]
- Failover Procedure – [Insert Draft Document Link]
- Failover Test Plan – [Insert Draft Document Link]
- Failover Test Report – [Insert Draft Document Link]
- Disaster Recovery Plan – [Insert Draft Document Link]
- Cloud Resilience Assessment – [Insert Draft Document Link]
- Critical Supplier Continuity Assessment – [Insert Draft Document Link]
- Redundancy Audit Checklist – [Insert Draft Document Link]
Startup-Focused Quick Summary
For a startup, do not begin with:
“How many servers should we buy?”
Begin with:
1. What services are critical?
Identify what the business cannot afford to lose.
2. What supports those services?
Map the dependencies.
3. What happens if each component fails?
Assess business impact.
4. Where are the single points of failure?
Document them.
5. Which failures require redundancy?
Make a risk-based decision.
6. Does the redundancy actually work?
Test it.
7. What happens if the redundant system also fails?
Connect the design to backup and disaster recovery.
Startup-Focused Final Takeaway
ISO 27001 Annex A 8.14 is about ensuring that critical information-processing capabilities do not depend unnecessarily on a single point of failure.
For a modern SaaS startup, redundancy may involve:
Multiple application instances + database availability + cloud availability zones + network resilience + backup connectivity + critical supplier resilience.
But redundancy should not become an exercise in buying duplicate infrastructure.
The right question is:
“What level of availability does the business require, what could cause unacceptable disruption, and what redundancy is justified by that risk?”
Simple Startup Model
Identify → Assess → Map → Find SPOFs → Define Requirements → Implement → Monitor → Test → Improve
And remember:
Redundancy keeps systems available. Backup helps recover information. Business continuity connects both to the needs of the business.
One-Line Summary
ISO 27001 Annex A 8.14 ensures that information-processing facilities have appropriate redundancy where required to meet availability needs and reduce the impact of failures and single points of failure.