What ISO 27001 A.8.14 redundancy asks for and why it fails
A.8.14 asks that information processing facilities are implemented with enough redundancy to meet availability requirements. In practice, a compliance lead must be able to show that the failure of a server, a site or a supplier does not turn into a service loss the organization has not planned for. The control is short, but the word "enough" carries the weight, and it only has meaning once the organization has defined what availability it needs for each service. The risk is simple to state. A single point of failure turns an ordinary component fault, such as a failed disk, a dead load balancer or an expired certificate on a shared gateway, into a full outage. The control is hard to satisfy for two reasons. First, availability targets are often undefined or exist only in a vendor contract, so there is nothing to size redundancy against. Second, engineering teams design the redundancy while compliance teams own the evidence, and the two often do not talk until an audit begins.
Start by listing the facilities that process information for each critical service, then record the availability requirement and the failover design that meets it. Confirm with your engineering leads whether each component, site and key supplier has a tested alternative, and whether that alternative would actually carry the load (A.8.6 capacity management is where this is checked). Closely related are A.8.13 information backup, which covers recovering data, and A.5.30 ICT readiness for business continuity, which covers the plans that bring services back. Redundancy addresses continuity of processing, so it should be assessed alongside both. The organization owns this control and decides how much redundancy is enough. An independent auditor tests whether that decision is documented, implemented and evidenced. Implementation partners can help prepare the architecture records, failover test results and monitoring data, but they do not decide the availability requirement or issue any assessment outcome.
Which systems, sites and suppliers fall under ISO 27001 A.8.14 redundancy
A.8.14 applies to the information processing facilities that the organization's availability requirements depend on, not to every server it owns. The scope decisions below determine which platforms, sites and suppliers need redundancy, which must be tested, and how the Statement of Applicability records the choice. Each decision should be made in writing and reflected in the SoA before the assessment begins.
Availability requirements per service
Start by naming which services carry availability requirements and at what level, such as payment processing, customer portals or internal ticketing. A.8.14 asks for enough redundancy to meet those requirements, so a single requirement for the whole estate usually produces weak evidence. Record the requirement owner, the tolerated downtime and the dependent components for each service, then trace each one to the facilities that host it. Only the traced facilities enter the control's scope.
Production and processing platforms
Decide which application platforms, container clusters and processing pipelines count as information processing facilities for the scope. A single failed node may be acceptable for a batch job but not for a transaction service. Document the active and standby arrangement for each platform, including whether failover is automatic or manual. An assessor will look for the platforms named in the scope and for evidence that each one has been designed around its stated requirement.
Storage, databases and identity services
Storage arrays, database clusters and identity services often become single points of failure because other systems depend on them. Decide whether replicas, quorum members and secondary directory instances are in scope, and document how each one fails over. Authentication outages can stop every service at once, so identity redundancy is a common gap. Confirm that these components appear in the asset inventory and the SoA, not only in the application diagrams.
Primary and secondary sites or cloud regions
Decide whether the secondary site is an on-premises data center, a colocation facility or a second cloud region, and whether it must survive the loss of the primary site or only a single zone. The answer sets the physical and network separation required and the distance between sites. Record the decision in the SoA, along with the sites that are explicitly excluded and the reason. A secondary site that has never carried production load should be tested before it is counted as redundancy.
Network paths and carriers
Redundant servers do not help if they share one network path or one carrier. Decide which links, routers, firewalls and carrier circuits are in scope, and whether diverse routes and carriers are required for each site. Ask the carriers for diagrams that show physical path separation, because two circuits can share a single duct or exchange. Record the agreed design in the network documentation and the SoA.
Inherited or verified supplier redundancy
Decide whether redundancy provided by a hosting provider, carrier or managed service is inherited from its contract and public documentation, or must be verified by the organization. Inherited redundancy still needs evidence, such as the provider's service commitments, architecture documentation and the organization's own failover test results. Critical third parties should appear in the supplier register with their redundancy claims recorded. Confirm the specific commitments in the contract, since general marketing language is not evidence of a given design.
How an assessor tests redundancy and failover under A.8.14
This table compares what an assessor reviews, the evidence requested and the findings that usually come up for each part of A.8.14. Read each row as a test the organization should be able to pass before the audit, with the common findings showing where redundancy claims tend to fail under scrutiny. The main takeaway is that a design diagram alone rarely satisfies an assessor without tests, dated results and proof that failed components are detected.
| Assessment area | What the assessor checks | Evidence requested | Common findings |
|---|---|---|---|
| Documented availability requirements | Whether availability targets for each information processing facility exist, who set them and how they were derived from business impact | Approved availability requirements, business impact analysis outputs, sign-off records and review dates | Availability requirements are not documented, or they exist only as informal expectations held by engineering |
| Redundant components | Whether critical components such as servers, storage, network devices and power feeds have a defined spare and the spare can take over the load | Architecture diagrams, capacity figures for active and standby components, configuration records | Redundancy is shown in diagrams but spare capacity is too small to carry peak load |
| Redundant sites and locations | Whether a second site or location exists for processing, its distance from the primary and whether it can run the required services | Site inventory, replication design, recovery location agreements, scope statement for the ISMS | Secondary site depends on the same utility, carrier or building as the primary |
| Redundant suppliers and providers | Whether critical services such as cloud regions, carriers, data center operators and key software vendors have an alternative or a documented fallback | Supplier register entries, contract terms on availability, documented alternative routes | Two providers are listed but both rely on one upstream supplier or one network path |
| Shared dependencies | Whether redundant paths share a single power feed, network entry, DNS, identity service or support team | Power and network single-line diagrams, dependency maps, change records showing path separation | Redundant servers share one power distribution unit, one rack switch or one authentication service |
| Failover and restore tests | Whether failover to redundant components and sites has been run, what was measured and whether results were acted on | Test plans, dated test records, observed recovery times against the stated requirement, corrective actions | Failover has never been tested end to end, or tests cover only component restarts and not service recovery |
| Monitoring of failed components | Whether the organization detects a failed or degraded component quickly enough to act and whether alerts reach a responder | Monitoring rules, alert history, escalation paths, sample incident tickets linked to alerts | Alerts exist for hosts but not for standby components, so a failed spare goes unnoticed until the next test |
| Link to risk assessment and continuity plan | Whether single points of failure found in the risk assessment have been treated and whether the continuity plan reflects the redundancy design | Risk register entries, treatment decisions, continuity plan sections, documented review of both | Continuity plan assumes a standby site that the risk register records as unavailable or unfunded |
Implementing redundancy for ISO 27001 A.8.14 in sequence
This sequence turns A.8.14 from a statement of intent into a documented, tested and reviewed set of redundant components, sites and suppliers, with records an assessor can follow from requirement to result. Each step produces an artifact the organization owns, whether or not an implementation partner helps build it.
Define availability requirements per service
Start by listing each business service that depends on information processing facilities, such as payments, patient records or customer portals. For each service, the control owner and business owner agree on the availability requirement, the acceptable downtime and the data loss tolerance, and record them in a service register. The step is done when every in-scope service has a documented requirement signed off by its owner, because every later design choice is judged against these numbers.
Map single points of failure
Trace each in-scope service through its components, the sites that host them, and the suppliers that provide power, network, hosting, DNS and software updates. Mark every element whose failure would breach a requirement from the previous step. The output is a dependency map or table of single points of failure, reviewed by both infrastructure and business owners. Ask the auditor early which level of detail they expect, since this map is the basis of the rest of the sequence.
Design and document redundancy
For each single point of failure, decide the response: duplicate the component, add a second site, contract a second supplier, or accept the risk with a named owner and a recorded reason. Capacity planning under A.8.6 should confirm that the surviving components can carry the load during failover. The output is a redundancy design document that links each requirement to the mechanism meeting it, and it should align with the backup and continuity records covered by A.8.13 and A.5.30.
Configure monitoring and alerting for failed components
Redundancy only helps if failures are noticed and acted on. Configure health checks, metrics and alert rules for every redundant component, including replication lag, failover readiness and supplier status where the platform exposes it. Open-source options such as Prometheus for metric collection and Grafana Alerting for rules and notification are commonly used for this purpose, but confirm each tool's capability in your own environment before relying on it. The output is a list of alert rules, their owners and sample alert records showing they fire and reach a responder.
Run failover and restore tests
Test each redundant path under controlled conditions: fail over a database, switch traffic to the secondary site, or withdraw a supplier and confirm the service continues within the requirement. For backed-up data, run restore tests and integrity checks, for example with restic check and its read-data options, which read pack files back to confirm the stored data is unmodified. Agree the test scope and timing with the people who run production so the tests do not disrupt business processes. Record the scenario, the observed result and the time to recover for each test.
Record results and corrective actions
Compare each test result with the availability requirement from the first step. Where a test fell short, open a corrective action with an owner, a cause, a fix and a verification step, and link it to the risk register. The output is a test report per scenario plus a corrective action log showing what was found, what changed and whether the retest passed. Assessors typically sample these records to check that the organization acts on results rather than only running tests.
Schedule periodic review
Set a review cycle for the redundancy design, the single point of failure map, the alert rules and the test plan, and trigger an extra review after significant changes such as a new site, a new hosting supplier or a major architecture change under A.8.32. Confirm the review frequency with your own risk assessment and internal audit program, because the appropriate interval depends on how quickly your environment changes. The output is a dated review log showing who reviewed each item, what changed and which decisions were revisited.
Evidence that satisfies ISO 27001 A.8.14 and how to keep it current
An assessor testing A.8.14 looks for a chain of evidence: what availability the business needs, how the facilities are built to meet it, what the suppliers and sites have committed to, and whether failover has actually worked. Each artifact below should be dated, owned and refreshed on a schedule so that it still describes the environment on the day of the audit.
Documented availability requirements
The written availability targets for each information processing facility, derived from business impact analysis and the risk assessment. Assessors use these to judge whether the redundancy design is proportionate. Check that every targeted service maps to a named facility and that the requirements were approved by someone with authority over the business process. Keep a version history and record each review date. After any significant change in service criticality, such as a new customer-facing product, reissue the document and note which design decisions it affected.
Architecture and redundancy diagrams
Current diagrams showing primary and secondary compute, storage, network paths, power and cooling dependencies, and the sites or availability zones they occupy. A diagram that hides a single shared dependency, such as one identity provider or one database cluster, will not survive review. Label each diagram with its date and the change record that last updated it. Review the design annually and after each material infrastructure change, and retain superseded versions so that the design in force at any past audit period can be shown.
Supplier and site contracts with availability terms
Hosting, colocation, network and cloud agreements that state availability commitments, service credits, maintenance windows and the supplier's own redundancy. Confirm that the contract terms match the availability requirements the organization has documented, not just the supplier's marketing figures. Record the expiry or renewal date of each agreement and the owner responsible for tracking supplier performance reports. Where a supplier's redundancy is part of the design, ask for its independent assurance evidence and note when it was last received.
Failover and restore test plans and results
Written test plans describing what is failed over, who runs the test, the expected recovery time, and the pass criteria, followed by dated results that show what actually happened. Assessors look for evidence that tests were run, that failures were recorded, and that follow-up actions were completed. Run a test after each significant change to the failover path and keep a schedule for periodic tests. Results should include timings and any manual steps the team had to perform, because those steps reveal gaps the diagram does not show.
Monitoring alert records for failed components
Exports or screenshots from monitoring that show alerts raised when redundant components degraded, such as a failed disk in a mirror, a lost network path or a stopped replica. An assessor will check that alerts reached a responsible person and were acted on. Self-hosted tools such as Prometheus with Grafana Alerting can produce these records, but confirm that alert history is retained for the audit period and that alert rules cover every redundant component listed in the design.
Corrective action logs
A register of each redundancy weakness found by a test, alert or incident, with the root cause, the corrective action, the owner, the due date and the verification that the fix worked. Assessors use this log to see whether the management system improves the design over time. Close each entry only after a retest confirms the fix. Review open items at management review, and keep the log current between audits so it shows a continuing cycle rather than a single clean-up before the assessment.
What meeting ISO 27001 A.8.14 costs in money and effort
This table breaks the cost of meeting A.8.14 into its components, shows which ones are paid once and which recur, and names the factors that push each cost up or down. No prices are given because none were supplied, so use the drivers and quote questions to compare written proposals. Read the recurring rows as the long-term commitment that keeps redundancy evidence current.
| Cost component | One-time or recurring | What drives it up or down | How to keep it down |
|---|---|---|---|
| Redundant infrastructure and capacity (second site, spare nodes, standby power, alternate network paths) | Mostly one-time to build, then recurring to run | Number of sites, availability targets, whether standby capacity is hot, warm or cold | Match redundancy tier to documented availability requirements; avoid duplicating components that no requirement names |
| Licenses for redundancy and clustering software | Recurring | Commercial versus open-source components, number of nodes, support tier | Choose self-hosted open-source platforms where they meet the requirement; confirm license terms in writing |
| Engineering time to design and document redundancy | One-time, with periodic revision | Number of information processing facilities, supplier count, architecture complexity | Document the design once per facility type and reuse the pattern; keep diagrams under version control |
| Failover testing effort (planning, execution, fixing gaps found) | Recurring per test cycle | Number of critical services, dependency depth, how often failover is tested, whether tests touch production | Test the highest-impact services first; automate repeatable failover steps; record results against the stated targets |
| Monitoring tooling for capacity and health of redundant components | Set-up one-time, run recurring | Number of metrics and alert rules, retention period, number of data sources | Self-hosted open-source monitoring such as Prometheus and Grafana can remove per-seat license spend; confirm storage and staffing needs |
| Backup and restore verification tooling | Set-up one-time, run recurring | Data volume, backup frequency, restore test scope | Self-hosted tools such as Bareos or restic can avoid license fees; budget for storage and restore test time |
| Evidence upkeep (test records, change records, diagrams, supplier redundancy evidence) | Recurring | Change rate, number of suppliers, number of sites, how evidence is stored | Collect evidence as part of routine change and test work rather than before audits |
| External testing or independent review | Recurring, often per engagement | Scope of review, number of facilities in scope, depth of failover testing requested | Agree scope in writing before work starts; ask whether review covers evidence or only design |
| Auditor sampling time | Recurring at each audit cycle | Number of sites in certificate scope, number of failover records the auditor samples, nonconformity follow-up | Keep one indexed evidence set per site; resolve gaps before the audit window |
Open-source tools that produce redundancy and failover evidence
Prometheus collects metrics from instrumented jobs through a pull model over HTTP and stores them as time series identified by metric name and labels on autonomous local storage. For A.8.14, that history can show whether redundant components such as nodes, database replicas or network paths were up, how much capacity remained during an incident and how quickly service recovered during a failover exercise. Queries written in PromQL can be saved and re-run during an assessment.
- Availability history: Scrape results and up metrics record whether each instrumented target responded over time, which can be compared against failover test dates.
- Local storage: Data is kept on the Prometheus server's own storage, so retention and disk sizing must be planned, and the organization should confirm how long records must be kept for its audit cycle.
- Instrumented jobs only: Components that do not expose metrics leave gaps, so an assessor will ask which redundant elements are covered.
- Saved queries: Stored PromQL expressions can be versioned in source control and rerun to show the same measurement method across periods.
- Apache-2.0 license: Organizations can review the license terms with their legal team before deployment.
Confirm that scrape coverage includes every redundant component in scope and that the retention period matches your evidence needs.
Grafana Alerting builds alert rules from queries and expressions across multiple data sources, alerts on metrics and logs together and lets teams create, manage and act on alerts from one view. For A.8.14, alert records show that the organization detected loss of a redundant component or site and acted on it. Notification history and acknowledgments can serve as evidence that failover conditions were noticed and handled in line with the organization's procedures.
- Multi-source rules: Rules can combine Prometheus metrics with log data, so a failed replica and a related error spike can be tied together in one alert.
- Single view: Teams can manage alert rules, silences and responses from one interface, which simplifies showing who handled a given alert.
- Notification evidence: Alert firing and resolution times can be compared with failover test records to show detection speed.
- Rule ownership: Rules must be reviewed and kept current as the architecture changes, otherwise they will report on components that no longer exist.
- AGPL-3.0-only license: The license carries obligations when the software is modified and offered over a network, so confirm the position with counsel before customizing it.
Check that every alert tied to a redundancy requirement routes to a named, staffed response group and that the alert history is retained.
The Bareos Director schedules and supervises backup, restore, verify and archive jobs, keeps a SQL catalog of backed-up files and restores files from the current backup or from one taken before a given date and time. For A.8.14, Bareos records show that backup copies exist at the required frequency and can be restored, which supports the redundancy of information held on the processing facilities. Bareos is a backup tool, so its records support the recovery argument but do not make a system redundant.
- Job records: The catalog and job logs show when backups ran, whether they succeeded and what was restored during exercises.
- Point-in-time restore: Restores from a chosen date and time can be used in tests that prove a recovery point meets the stated objective.
- Verify jobs: Verify jobs compare stored data with the catalog, giving assessors a documented check on backup integrity.
- Catalog protection: The SQL catalog is a critical dependency, so it must be backed up and protected, or the restore evidence itself is lost.
- AGPL-3.0-only license: Review the license terms with counsel, particularly if the tool is changed or bundled into a service.
Confirm that restore tests run against a separate target that matches production, not only against the original host.
restic is a backup tool under the BSD-2-Clause license. Its check command verifies the structural consistency of snapshots, trees and pack files, and with --read-data or --read-data-subset it reads pack files back to confirm the stored backup data is unmodified. For A.8.14, this gives a repeatable integrity check on the copies that a failover or restore would depend on. As with other backup tools, the output supports the redundancy argument but does not create redundancy by itself.
- Structural checks: A routine
restic checkrun can show that repository structures are consistent, with results retained as evidence. - Data read-back: The
--read-data-subsetoption lets teams check part of a large repository on a schedule, while--read-datacovers the full repository when time allows. - Restore testing: Pairing checks with restore tests shows that the data can actually be recovered to a working state.
- Repository placement: Copies should sit in a separate failure domain, such as another site or account, so that a single failure does not remove both the data and its backups.
- BSD-2-Clause license: This permissive license generally imposes light conditions, but the organization should still confirm them against its own policies.
Confirm the check schedule, the read-data scope and the location of the repositories against your recovery objectives.
Where organizations fall short on redundancy and how to close each gap
Most redundancy failures are not missing hardware. They are availability targets nobody wrote down, single points of failure hidden behind apparent duplication, and recovery steps that were never exercised. The cards below pair each gap with the step that closes it, so the evidence an assessor asks for exists before the audit starts.
Availability requirements never written down
A.8.14 asks that information processing facilities have enough redundancy to meet availability requirements, but many organizations never state what those requirements are. Without written recovery time and recovery point objectives per service, no one can say whether a design is sufficient. Write the availability target for each critical service, have the business owner approve it, and link each target to the design components that support it. An assessor will check whether the design traces back to a stated requirement.
Hidden shared dependencies
Two servers, two data centers or two firewalls can still fail together if they share one power feed, one network path, one DNS provider or one identity service. Map each redundant pair down to the power, network, cloud region and supplier layers it depends on. Where the map shows a shared element, decide whether to separate it or document it as an accepted risk with an owner. Illustrative example: a cluster split across two racks that both draw from one upstream power distribution unit has redundancy only on paper.
Failover never tested end to end
Replicated systems often pass component checks while the full failover path fails under real conditions, for example when DNS, certificates, secrets or load balancer health checks are not switched with the workload. Run a scheduled end-to-end failover for each critical service, record the measured switchover time, and compare it with the stated objective. Keep the test plan, timings, defects and retest results. Monitoring tools such as Prometheus and Grafana Alerting can capture the evidence of when services degraded and recovered.
Backups that cannot restore in time
A backup set proves that data was copied, not that the business can recover within its objective. Restore speed depends on catalog state, bandwidth, storage tier and the order in which systems must come back. Time a full restore of a representative system into an isolated environment and compare the result with the recovery time objective. Verify backup integrity regularly; for example, restic check with --read-data or --read-data-subset reads pack files back to confirm stored data is unmodified. Related controls such as A.8.13 Information backup cover the backup policy itself.
Supplier redundancy assumed, not verified
A second cloud region, colocation provider or managed service is only redundancy if its contract, capacity and independence have been checked. Ask each critical supplier for its own availability commitments, the location of its facilities, its dependencies on other providers and its tested failover procedure. Confirm that the secondary supplier can take the load within the stated objective, and that exit or switching terms exist in writing. Supplier evidence should be reviewed at least as often as the supplier contract renews.
Redundancy without monitoring or review
Redundant components degrade silently. A failed disk in a mirror, an unhealthy replica or a standby that stopped syncing can leave a service with no remaining margin while every dashboard still shows green. Define health signals for each redundant element, alert when a component loses its pair, and assign an owner to respond. Review the redundancy status in management and capacity meetings, and keep the records. This connects A.8.14 to A.8.6 Capacity management, since a surviving node that is overloaded does not provide the availability the design promised.
Who does what: your team, an implementation partner and the auditor
Your organization owns the control. A.8.14 asks that information processing facilities are implemented with enough redundancy to meet availability requirements, so the first decision is what those requirements are. Business owners, not the implementer, should state how long each service may be unavailable and how much data loss is tolerable, and the security and operations leads should convert those statements into design targets. Your team also decides which risks are accepted, records the control's entry in the Statement of Applicability, and signs off on every failover test result before it becomes evidence.
- Availability requirements: Document the recovery expectations for each critical service, agreed by the business owner and approved by management.
- Risk decisions: Record which single points of failure remain and who accepted them, with the reasoning.
- Statement of Applicability entry: State how A.8.14 applies to your scope and link it to the design documents and test records.
- Test sign-off: Review each failover test report, confirm the results met the stated targets, and decide on corrective actions.
- Supplier decisions: Confirm which cloud regions, data centers or hosting providers you rely on and what they commit to in contracts.
Before engaging anyone, confirm that these decisions are written down and owned internally, because an assessor will ask the organization, not the partner, why the design is adequate.
An implementation partner such as DeployOpen works inside your infrastructure, which may be your cloud accounts, data centers or air-gapped networks, to plan, implement and document redundancy for the self-hosted platforms in scope. The partner can prepare the technical evidence the control depends on: architecture records, configuration of replicated components, monitoring that shows whether standby capacity is healthy, and failover test scripts with logs. Where the scope is agreed in writing, the partner can also run the tests and report the results to your team. The partner does not decide your availability targets, accept risk on your behalf or issue any certification.
- Design and build: Plan redundant components, sites or suppliers for the agreed platforms and implement them in your environment.
- Test preparation: Write failover test scripts and runbooks that your team can review and repeat.
- Evidence preparation: Collect configuration exports, monitoring dashboards and test outputs in a form an assessor can sample.
- Scoped test execution: Run failover tests when the written scope includes them, with agreed windows and rollback steps.
- Documentation and handover: Deliver architecture records and runbooks, and train the staff who will operate and retest the setup.
Ask the partner to name in the statement of work exactly which systems, sites and tests are covered, because anything outside that list will still be your responsibility at audit time.
The auditor is an independent certification body or assessor. It tests whether A.8.14 is operating as described, samples the evidence, interviews staff and reviews how your team decided the requirements and accepted the residual risk. Only the certification body issues a certificate, and the assessor must be independent of the organization and of any firm that designed or implemented the controls. ISO does not certify organizations, and DeployOpen does not issue audit reports, attestations or certifications.
- Independent testing: The assessor checks the design against the stated availability requirements and samples test records for evidence of execution.
- Evidence sampling: Expect requests for dated test results, change records and monitoring history rather than verbal assurance.
- Interviews: Staff who run the platforms should explain how a failover is triggered and who decides to invoke it.
- Findings: Gaps are reported as nonconformities or observations, and your organization responds with corrective actions.
- Certificate decision: The certification body alone decides whether the management system meets the standard.
Before the audit, confirm the certification body's accreditation status through the IAF CertSearch database, since ISO points to it for checking accredited certificates.
Outsourcing parts of A.8.14 is common, but independence has limits. The organization can outsource building and testing, yet it cannot outsource accountability for the availability requirements or the risk decisions. The auditor cannot be the same firm that designed or ran the redundancy, because that would remove the independent check the certification depends on. Clear role boundaries protect both sides: the partner gives you evidence and the auditor tests it.
- Usually outsourced: Architecture design, redundant platform deployment, failover script writing and scheduled test execution.
- Usually kept internal: Availability targets, risk acceptance, Statement of Applicability content and test sign-off.
- Shared: Runbook maintenance and periodic retesting, where internal staff should be able to repeat the work without the partner.
- Never combined: The partner that built the controls should not also be the certification body or the auditor for the same scope.
- Contract points: Define who owns the evidence, who may access the environment during audit sampling and how changes are recorded.
Before signing, ask the partner how it will support the auditor's sampling requests without preparing reports that claim to be audit results.
Questions buyers ask about ISO 27001 A.8.14 redundancy
How much does outside help for A.8.14 redundancy cost?
No supplied fact gives a price for this work, so the cost depends on the written scope. The main drivers are the number of information processing facilities in scope (production sites, cloud regions, data centers), how many redundant components already exist, how many failover paths need design or rebuilding, and whether monitoring, backup and documentation work is included. Costs fall into two groups: one-time work to design, build, test and document redundancy, and recurring work such as periodic failover tests, upgrades and evidence refreshes. Ask any provider for a quote that lists each system in scope, each deliverable, who performs each task and which items are one-time or recurring. DeployOpen does not publish a price list; a quote follows from the written scope.
How long does it take to make systems redundant enough for A.8.14?
The timeline is set by the current state of the environment and by how much change the design requires, not by the control itself. Work that usually takes longest includes assessing existing single points of failure, agreeing availability requirements with the business, procuring or provisioning a second site or supplier, migrating workloads and running failover tests that the business accepts. Engagements are usually fixed-scope, so the written scope should state milestones, dependencies on the client's change windows and the staff who must be available. Ask for a schedule that separates design, build, test and evidence collection, and confirm which steps depend on hardware lead times or supplier contracts.
What does the client's team have to provide during the engagement?
The organization owns its controls, so its own people must make the decisions the control depends on. Expect the client to provide:
- Defined availability requirements for each service, approved by business owners
- Access to infrastructure, cloud accounts or data center records, and change approval
- Named owners for each system, supplier and failover procedure
- Time for stakeholders to review designs, attend failover tests and sign off results
- Existing risk assessment, business impact analysis and backup policy material, where they exist
An implementation partner can prepare the systems, configuration and evidence, but it cannot set the availability targets or accept residual risk for the organization. Confirm these responsibilities in the written scope before work starts.
Can a small team handle A.8.14 redundancy without outside help?
A small team can do it alone if it has the skills to design and operate redundant infrastructure, time to run failover tests, and a clear owner for availability decisions. The hardest parts for a small team are usually the single points of failure hidden in shared networks, identity services, DNS, supplier dependencies and monitoring, and the discipline to repeat failover tests and record results. Outside help is most useful when the team lacks capacity for the build, needs an independent view of the design or wants a repeatable test and evidence routine. Assess the team's capacity against the list of systems in scope, then decide which parts to keep in-house and which to scope out.
Can a partner run failover tests for redundant systems?
Yes, a partner that builds self-hosted open-source platforms can plan and run failover tests on systems it deploys, including tests of redundant components, alternate sites and backup restores. Tests should be written as scenarios with expected results, run in agreed windows, and recorded with timings, errors and follow-up actions. Monitoring tools such as Prometheus and Grafana Alerting can show whether failover was detected and whether alerts reached the right people, and restic and Bareos can show whether backup data restores as expected. Ask the partner which tests it will run, which systems each test touches, how production impact is controlled and how results are retained as evidence.
Can the partner certify us against ISO 27001?
No. Only an independent accredited certification body can issue an ISO 27001 certificate, and an assessor performs the audit. An implementation partner such as DeployOpen prepares systems, controls and evidence, including redundancy design, failover test records and supporting documentation, but it does not issue audit reports, attestations or certificates. For independence, the partner that builds the controls should not also be the auditor. Before hiring, check that the certification body is accredited for ISO/IEC 27001 and ask the auditor which evidence it expects for A.8.14.
What evidence will show that A.8.14 is met?
An assessor will look for proof that redundancy was chosen against documented availability requirements and that it works in practice. Typical evidence includes the availability requirements, architecture diagrams showing redundant components, sites and suppliers, the risk assessment that justified them, failover test plans and recorded results, monitoring configuration and alert history, and records of corrective actions. Ask the auditor, in writing, which artifacts it accepts and how often it expects tests to be repeated, because the expectations depend on the organization's own requirements and risk decisions.
How DeployOpen scopes, implements and prepares A.8.14 evidence
DeployOpen works on A.8.14 as an implementation partner: we help map which information processing facilities need redundancy, build or configure that redundancy inside your own infrastructure, and prepare the failover evidence an assessor will ask for. Your organization keeps ownership of the control, its availability requirements and the decisions about acceptable risk. An independent auditor or certification body is the only party that issues a report or certificate.
How we scope
- Agree in writing which systems, sites, network paths and suppliers fall within the redundancy scope.
- Record the availability requirements your organization has set, so each redundant component traces back to a stated need.
- Confirm which alternate sites, backup services and cloud regions your Statement of Applicability will cite for A.8.14.
How we build
- Configure redundant compute, storage and network components in your accounts, data centers or air-gapped networks.
- Set up monitoring with Prometheus and Grafana Alerting so capacity and component health are visible before a failure.
- Align backup and restore paths with Bareos or restic so recovery targets are supported by the deployed architecture.
How we hand over
- Document the architecture, failover procedures and ownership of each redundant component in a form your team can maintain.
- Deliver failover test plans, test records and the monitoring and alert configuration that show redundancy works as designed.
- Provide a written evidence list mapping each artifact to A.8.14 so your internal review or auditor can trace it quickly.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask us to confirm during scoping which evidence your certification body expects, since assessors decide what is sufficient.
