Redundancy of information processing facilities

What the requirement asks

Information processing facilities are to be built with enough redundancy to satisfy availability requirements. Purpose: keep processing facilities operating without interruption. Guidance: identify availability requirements for business services and information systems and design and build a systems architecture with redundancy that meets them. Redundancy can mean duplicating facilities partly or completely, from spare components to two of everything. Plan and implement procedures for bringing redundant components and facilities into use, stating whether they are always active or activated automatically or manually in an emergency; redundant elements must be secured as strongly as the primary ones. Mechanisms should alert the organization to failures, allow the planned procedure to run and keep services available while facilities are repaired or replaced. Consider contracting several providers for network and critical processing services, internet access among them; redundant networks; mirrored systems in two data centres in different locations; physically redundant power supplies or sources; multiple parallel software instances with automatic load balancing within or across data centres; and duplicated components within systems (processors, disks, memory) or networks (firewalls, routers, switches). Where it applies, and ideally on live systems, test that failover between components works as intended. Other information: redundancy is closely linked to ICT readiness for continuity (5.30), especially where recovery times are short; copying data to duplicates can introduce integrity errors and weakly secured duplicates can compromise confidentiality, so both must be designed for; redundancy does not usually cure faults within an application; public cloud allows multiple live copies in several places, failing over and balancing load automatically, discussed in ISO/IEC TS 23167. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

Redundancy is a design choice with a cost. The guidance asks for the component, the failure mode, the switchover and the test.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep documented availability requirements for business services and systems and one live sample together.

Evidence an assessor asks for

• Availability requirementsDocumented availability requirements for business services and systems
• Availability requirementsArchitecture diagrams showing redundancy such as dual providers, redundant networks, separate data centres, redundant power and load-balanced instances
• Availability requirementsProcedures for activating redundant components, stating whether activation is automatic or manual
• Availability requirementsFailover test records, preferably from production, showing failover worked as intended
• Availability requirementsMonitoring and alerting configuration for component failures
• Availability requirementsEvidence that redundant components carry the same security controls as primary ones

The question an assessor will ask

An assessor will ask for documented availability requirements for business services and systems, then trace it to the system it protects. For A.8.14 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common gaps

• Redundant components exist but failover has never been tested
• Both internet links run through the same physical route or provider
• The secondary site has weaker security controls than the primary
• Single points of failure remain in supporting components such as DNS or identity services

Before the next audit

Before the next audit, check one live sample for this gap: redundant components exist but failover has never been tested.