ISO 27001 Annex A 8.14 requires information processing facilities to have sufficient redundancy. This documented process ensures systems meet availability requirements. You must integrate these procedures into existing tools like SharePoint. It involves planning for component failures without relying on external software platforms. This maintains operational continuity through management oversight.
Table of contents
Auditor’s Eye: The Shortcut Trap
Many organisations rely on automated SaaS platforms to track availability. These platforms show a green tick but lack internal testing evidence. Auditors reject these black box records. We want to see your native repositories. Show me Jira tickets for your last failover test. Confluence must host your architecture diagrams. Relying on SaaS decouples security from daily work. Authentic evidence resides in your document versions. This proves you own the resilience process.
| ISO 27001:2013 Control | ISO 27001:2022 Control | Nature of Change |
|---|---|---|
| A.17.2.1 Availability of info processing facilities | Annex A 8.14 Redundancy of info processing facilities | Shift from generic availability to specific redundancy requirements. Emphasises resilience of facilities. |
How to Implement ISO 27001 Annex A 8.14
Redundancy is a documented state of system resilience. It is not a software installation. You must use existing organisational tools to build a audit trail. This ensures technical teams follow security protocols naturally. Follow these steps for implementation:
- Define availability targets in a SharePoint document.
- Link targets to your Business Impact Analysis.
- Draft technical redundancy diagrams in Confluence.
- Record system configurations for failover clusters.
- Create Jira tickets for quarterly failover tests.
- Document test outcomes in the Jira comments.
- Assign technical owners to maintain redundant hardware.
- Review resilience during monthly management meetings.
ISO 27001 Annex A 8.14 Audit Evidence Checklist
Focus on manual records and internal document versions. These prove human oversight and intent. Maintain these in your primary organisational tools:
- Business Impact Analysis in SharePoint.
- Redundancy architecture diagrams in Confluence.
- Failover test logs in Jira.
- Management meeting minutes reviewing resilience.
- Service Level Agreements with hardware vendors.
- Historical uptime reports from internal monitoring.
Relational Mapping
Annex A 8.14 depends on several core ISO 27001 controls:
- Annex A 5.30: ICT readiness for business continuity.
- Annex A 8.13: Information backup requirements.
- Annex A 8.20: Network security and redundancy.
Auditor Interview
Auditor: How do you verify your redundancy works?
Manager: We perform quarterly failover tests. We track every test in Jira.
Auditor: Where is the design documentation for your cluster?
Manager: All architecture diagrams reside in Confluence. You can see the version history there.
Auditor: How do you define the required level of redundancy?
Manager: Our SharePoint BIA defines the availability targets for each service.
Common Non-Conformities
| Failure Mode | Description | Corrective Action |
|---|---|---|
| Automated Complacency | Relying on a SaaS platform tick without internal test logs. | Record manual failover tests in Jira. |
| Single Point of Failure | Systems lack redundancy for power or networking components. | Update Confluence diagrams to identify gaps. |
| Stale Documentation | Redundancy plans exist but do not match live hardware. | Implement monthly document reviews in SharePoint. |
Frequently Asked Questions
The bottom line: Small tech businesses with under 10 people must ensure their core cloud infrastructure has no single point of failure by configuring environmental redundancy. You must document your failover mechanisms, such as active-active database clusters, before moving into compliance automation platforms like Vanta or Drata.
Annex A 8.14 mandates that your information processing facilities have sufficient redundancy to meet your availability requirements. For a lean AI company, this typically means demonstrating that if a primary cloud Availability Zone drops, your application automatically shifts traffic to a secondary zone without manual engineering intervention.
The bottom line: You must provide architectural diagrams showing Multi-AZ deployments and load balancers, alongside documented SLA agreements guaranteeing at least 99.9% uptime. Presenting screenshot evidence of configured auto-scaling groups acts as indisputable proof for your ISO 27001 audit.
Auditors know modern SaaS businesses rely on cloud giants. To pass this control, capture infrastructure-as-code (IaC) snippets or cloud console configurations that prove redundancy is actively enabled. Relying purely on the cloud provider’s general marketing promises, without demonstrating your specific tenant configuration, will result in an immediate non-conformity.
The bottom line: ISO 27001 does not mandate a universal uptime percentage like 99.99%; instead, acceptable downtime is dictated by your own business impact analysis. If your startup guarantees a 4-hour Recovery Time Objective (RTO) to clients, your redundancy architecture must mathematically support that specific target.
For an AI or tech business, prolonged downtime directly impacts early customer trust and revenue. You need to align your commercial Service Level Agreements (SLAs) with your technical redundancy capabilities. Ensure that your automated failover tests confirm your infrastructure recovers well within your stated RTO limits.
The bottom line: No, a fully remote 10-person business does not need physical office redundancy or secondary data centres. You simply need to verify that your staff have backup internet connections (such as 4G/5G mobile tethering) to ensure continuous operational access to your cloud resources.
The focus of Annex A 8.14 scales to your operations. For lean start-ups operating entirely in the cloud without physical servers, the redundancy focus shifts to remote access pathways and resilient cloud architecture. Ensuring your team can still deploy code or manage databases during a local broadband outage satisfies the intent of the control.