SekitCrosswalk
ISO/IEC 27001:2022 · derived mapping target

A.8.14Redundancy of information processing facilities

Build in enough redundancy across your processing facilities to meet your availability requirements, so a single failure does not stop the business.

Mapped from the Sekit CSF

The Sekit controls that cover this requirement, lens by lens.

RCF-0252RTO/RPO definitions · TechnicalsupportsThe RTO/RPO technical facet builds the backup and recovery architecture to demonstrably meet documented recovery targets, the availability leg A.8.14 asks a redundancy design to satisfy.RCF-0255DR exercises · TechnicalsupportsThe DR-exercise technical facet rehearses recovery into an isolated environment without touching production, proving A.8.14's redundancy works under test rather than assumed on paper.RCF-0282Business impact analysis · TechnicalenablesThe business impact analysis technical facet enables dependency mapping across systems and suppliers, the visibility A.8.14 needs to decide which processing facilities warrant redundancy.RCF-0285Continuity plans · TechnicalsupportsThe continuity-plan technical facet keeps recovery plans and contact lists reachable when primary systems are down, so A.8.14's redundancy strategy can be executed when it matters, during an incident.RCF-0288Crisis management · TechnicalrelatedThe crisis-management technical facet provisions an out-of-band channel for the crisis team to coordinate, a related capability that supports A.8.14's redundancy goals during the outage a redundancy failure would trigger.RCF-0406SRE/Resilience practices · PolicysupportsThe SRE policy facet commits to reliability engineering practices and defined service level objectives, the written intent behind A.8.14's expectation that redundancy is designed in, not bolted on.RCF-0408SRE/Resilience practices · TechnicalenablesThe SRE technical facet enables monitoring of reliability indicators that automatically triggers alerts or recovery actions, turning A.8.14's resilience commitment into an automated response.RCF-0409Availability management · PolicysupportsThe availability policy facet sets written targets for every critical service, agreed with management, the baseline A.8.14 needs before redundancy decisions can be prioritized.RCF-0411Availability management · TechnicalenablesThe availability technical facet enables automated uptime monitoring against each service's target with alerts the moment it degrades, the ongoing check that keeps A.8.14's redundancy honest.

NIST CSF 2.0 counterparts

Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.

Evidence that proves this control

What an auditor, or Sekit's evidence engine, asks for.

Disaster recovery plan and runbooks
The plan defining how long each critical system can be down (RTO/RPO) and the step-by-step guides to recover it after a serious failure.
Availability and capacity management
How the company ensures its critical services are available as expected, plans their capacity, and prevents problems from recurring.
From the Sekit evidence catalog

In practice

Redundancy gaps at SMEs usually trace to a single point that was never meant to become permanent: one region hosting the whole application, one on-call engineer who understands the failover process, or a database with no standby replica because the extra cost was deferred at launch. Recovery time and recovery point targets get written into a plan, but the architecture behind them was never tested against those numbers, so nobody knows whether a regional outage would meet the stated RTO. A working setup defines availability targets per critical service, monitors uptime against them automatically, and rehearses failover into an isolated environment on a recurring schedule, so the numbers in the plan match what the infrastructure can deliver.

Common gaps

The application runs from a single region with no tested failover, so a regional outage would stop the business rather than degrade it.
RTO and RPO targets exist in the continuity plan but the architecture has never been tested against them, so the numbers are guesses.
Uptime is checked informally when a customer complains rather than monitored automatically against a defined availability target.

Questions your auditor will ask

What is the recovery time objective for your most critical service, and has it been tested?
The disaster recovery plan sets an RTO per critical service, and the most recent failover drill confirmed recovery within that target.
How do you monitor whether services meet their availability targets?
Automated uptime monitoring checks each critical service against its target continuously and alerts the responsible person when it degrades.
Can the crisis team communicate if the normal chat and email platform goes down?
Yes, an out-of-band communication channel is provisioned specifically for coordination when primary systems are unavailable or compromised.
How do you know which systems and processes depend on each other during an outage?
A dependency map, built from the asset inventory, links systems, suppliers, and processes so the impact of losing any one is understood in advance.

Where regulation demands it

NIS2 4.1 requires documented business continuity and disaster recovery plans, and ENS op.cont.1 requires an impact analysis behind them that identifies which systems need redundancy first.

Related controls

Via the shared Sekit CSF topic, not the framework's own index.

Ask Sekura: “What evidence proves A.8.14?”
Also via MCP, free with account