A single database server fails during peak operations. There’s no failover, no replica standing by. Hours pass before service returns, and every transaction between the last backup and the crash is gone. The gap between “we have backups” and “we stay online” is exactly what ISO 27001 control 8.14 exists to close.
What 8.14 Requires
ISO 27001 control 8.14 requires organizations to architect information processing facilities with sufficient redundancy — such as failover clusters or mirrored systems — to meet availability requirements and ensure continuity during component failures.
The operative word is sufficient. The standard does not demand blanket redundancy across every system. Instead, it expects redundancy proportional to business criticality. A customer-facing payment platform needs a different redundancy posture than an internal wiki.
This control is distinct from 8.13 (Information Backup), as defined in ISO/IEC 27002:2022. Backup restores data after a loss event; redundancy prevents downtime from occurring in the first place. A nightly backup won’t help if a failed load balancer takes your application offline for six hours. Control 8.14 addresses operational continuity — keeping services running through component failures, not recovering them afterward.
Why 8.14 Matters
Consider a mid-sized financial services firm running its core transaction platform on a single database server. The server’s storage controller fails on a Monday morning. There is no replica, no failover cluster. The team scrambles to restore from the previous night’s backup, but the process takes four hours. Every transaction processed between the backup window and the failure is lost entirely, requiring manual reconciliation that stretches into the following week.
This scenario is not hypothetical in pattern. According to the Uptime Institute’s 2024 Global Data Center Survey, 54% of organizations reported that their most recent significant outage cost more than $100,000, with one in five exceeding $1 million. More critically, four in five operators stated the downtime was preventable with better management and processes — including redundancy planning.
Availability is the most under-invested pillar of the CIA triad. Organizations routinely spend on encryption and access controls while running critical services on architectures with no failover path. The consequences span operational disruption, direct financial loss, reputational damage, and regulatory exposure.
What attackers exploit
Lack of redundancy creates predictable failure points that both incidents and adversaries can leverage:
- Single-point network infrastructure — one ISP link, one firewall, one core switch
- Unprotected power systems — no UPS or generator backup for critical equipment
- Database servers without replication — a single instance with no clustering or mirroring
- Single-zone cloud deployments — all resources in one availability zone, vulnerable to zone-level failures
- Untested failover mechanisms — redundancy exists on paper but has never been activated under real conditions
- Configuration drift on standby systems — redundant components running different patch levels, outdated configurations, or default credentials
How to Implement 8.14
Implementation splits into two tracks: what you build internally and what you verify in your supply chain.
For your organization (first-party)
1. Conduct a Business Impact Analysis (BIA). Identify which information processing facilities are critical to operations and define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for each. The BIA — a core element of any business continuity plan — determines where redundancy investment is justified and at what level.
2. Map single points of failure. Walk through each layer of your infrastructure — power, network, compute, storage, and application — and identify components where a single failure would cause service disruption. Document each SPOF and its blast radius.
3. Select redundancy models. Match the model to the workload:
- Active-active for high-traffic, stateless services where both nodes handle production load
- Active-passive for databases and stateful systems where a standby takes over on failure
- N+1 for clusters where one additional node absorbs the load of any single failed member
4. Implement layered redundancy. Apply redundancy at each infrastructure layer:
- Dual power supplies and UPS with generator backup
- Redundant ISP connections with automatic failover
- RAID or mirrored storage for data persistence
- Database clustering or replication
- Load balancers distributing traffic across multiple application instances
5. Design for cloud resilience. For cloud-hosted services, deploy across multiple availability zones at minimum. For the highest-criticality workloads, evaluate multi-region architectures. Being “in the cloud” is not a redundancy strategy — it requires deliberate configuration.
6. Secure redundant systems identically. Standby and secondary systems must receive the same patching, hardening, and access controls as primary systems. A failover target running an unpatched OS or default credentials is a liability, not a safeguard.
7. Test failover regularly. Simulate failures on a defined schedule. Document each test: scenario, expected recovery time, actual recovery time, and any remediation actions. Feed results back into architecture decisions.
Common mistakes to avoid:
- Implementing redundancy but never testing failover under realistic conditions
- Replicating data across regions without considering data sovereignty requirements
- Leaving standby systems unpatched or configured with default credentials
- Treating cloud hosting as inherently redundant without configuring multi-AZ deployments
- Failing to update redundancy designs after major infrastructure changes
Evidence to produce: BIA with RTO/RPO definitions, architecture diagrams showing eliminated SPOFs, failover test reports with measured recovery times, and a documented redundancy policy.
For your vendors (third-party assessment)
When critical services depend on third-party providers, 8.14 compliance extends to your supply chain. Include these questions in vendor risk assessments:
- “Describe your redundancy architecture for the service we consume.”
- “What are your committed RTO and RPO for this service?”
- “How frequently do you test failover, and can you share test reports?”
- “Do you operate across multiple availability zones or regions?”
Evidence to request: Architecture diagrams, SLA documentation with uptime commitments, failover test reports, and incident history showing actual recovery times.
Red flags:
- Vendor cannot state specific RTO/RPO figures
- Uptime claims (e.g., “99.99%”) lack supporting documentation
- No documented failover tests
- Single-region deployment for services you classify as critical
- Reliance on a sub-processor with no disclosed redundancy posture
Verification: Request SOC 2 Type II reports covering the availability trust service criterion. Review uptime monitoring data independently. Ask for post-incident reports showing actual recovery times against stated RTO commitments.
Audit Evidence for 8.14
Auditors verify that redundancy is designed, documented, tested, and maintained. Your information security policy should reference redundancy requirements explicitly. Prepare the following evidence:
| Evidence Type | Example Artifact |
|---|---|
| Business Impact Analysis | BIA report defining critical systems with RTO and RPO for each information processing facility |
| Redundancy Policy | Documented policy specifying redundancy requirements, architecture standards, and review cadence |
| Architecture Diagrams | Network and infrastructure diagrams showing redundant components and eliminated single points of failure |
| Failover Test Reports | Records of scheduled failover simulations including test date, scenario, recovery time achieved, and remediation actions |
| Monitoring Dashboards | Exports from monitoring tools showing replication status, uptime metrics, and alerting configuration |
| Change Management Records | Evidence that redundancy configurations are reviewed and updated after major infrastructure changes |
| Vendor SLA Documentation | Service level agreements with third-party providers specifying availability commitments and redundancy provisions |
Cross-Framework Mapping
Control 8.14’s redundancy requirements align with availability and continuity controls across major frameworks. Organizations pursuing vendor risk management across multiple standards can leverage shared evidence:
| Framework | Equivalent Control(s) | Coverage |
|---|---|---|
| NIST 800-53 | CP-02 (Contingency Planning) | Full |
| NIST 800-53 | CP-06 (Alternate Storage Site) | Full |
| NIST 800-53 | CP-07 (Alternate Processing Site) | Full |
| SOC 2 | A1.2 (Recovery of Infrastructure) | Partial |
| NIST CSF 2.0 | PR.IR (Infrastructure Resilience) | Partial |
| CIS Controls v8.1 | 11.4 (Isolated Instance of Recovery Data) | Partial |
| DORA (EU) | Article 11 (ICT Business Continuity Policy) | Partial |
Organizations can use security questionnaire automation to verify vendor alignment across these frameworks. They can also use 8.14 implementation artifacts — particularly the BIA, architecture diagrams, and failover test reports — as shared evidence across these frameworks.
Related ISO 27001 Controls
Control 8.14 operates within a network of related controls that collectively address availability, continuity, and infrastructure resilience:
| Control ID | Control Name | Relationship |
|---|---|---|
| 8.13 | Information Backup | Complementary — backup restores data; redundancy maintains availability |
| 5.30 | ICT Readiness for Business Continuity | Redundancy feeds into broader business continuity management planning |
| 7.11 | Supporting Utilities | Power and environmental redundancy (UPS, generators) |
| 7.8 | Equipment Siting and Protection | Physical placement and protection of redundant equipment |
| 8.20 | Networks Security | Redundant network paths require consistent security controls |
| 8.6 | Capacity Management | Redundant systems must have sufficient capacity to absorb failover load |
| 8.9 | Configuration Management | Redundant systems must remain synchronized with primary configurations |
| 5.29 | Information Security During Disruption | Maintaining security posture during failover events |
Frequently Asked Questions
What is ISO 27001 8.14?
ISO 27001 control 8.14 requires organizations to implement sufficient redundancy — failover clusters, mirrored systems, replicated databases — so that operations continue when individual components fail. It focuses on operational continuity rather than data recovery after the fact.
What happens if 8.14 is not implemented?
Without redundancy, a single component failure can take down critical services — causing extended downtime, data loss between backup intervals, and direct financial impact. In an audit, the absence of documented redundancy measures constitutes a nonconformity that blocks certification.
How do you audit 8.14?
Auditors verify that redundancy is designed, documented, and tested. They review the BIA for criticality-to-redundancy alignment, examine architecture diagrams for remaining SPOFs, inspect failover test reports for regular testing evidence, and check monitoring configurations for active redundancy tracking.
How UpGuard Helps
UpGuard’s platform provides continuous monitoring of your vendors’ security posture, including availability and redundancy indicators. Track whether critical third-party providers maintain the infrastructure resilience your redundancy requirements demand.