Availability

ISO/IEC 27000 defines availability as the property of being accessible and usable on demand by an authorised entity. Operationally it is expressed as a ratio, A = MTBF / (MTBF + MTTR), where MTBF is mean time between failures and MTTR mean time to repair or restore. The "nines" convert directly into downtime budgets: 99.9 % allows about 8.8 hours of unavailability per year, 99.99 % about 53 minutes and 99.999 % about 5.3 minutes. Because MTTR sits in the denominator, faster detection and recovery often buy more availability than more reliable hardware.

Components combine predictably. In a serial chain where every part must work (DNS, load balancer, application, database), availabilities multiply, so four components at 99.9 % each give roughly 99.6 % overall. Redundant components in parallel fail only together, giving 1 − (1 − A1)(1 − A2), which is why N+1 designs, clusters and multiple availability zones are the standard tool. The caveat is common-mode failure: two replicas sharing a power feed, a configuration push, an expired certificate or a single identity provider fail at the same moment, and replication faithfully copies deleted or encrypted data to the standby.

Continuity planning adds two targets per service. The recovery time objective (RTO) is how long the service may be down, and the recovery point objective (RPO) is how much data, measured in time, may be lost. Both come out of a business impact analysis, as in ISO 22301, and drive the choice between restoring from backup, warm standby and active-active operation. ISO/IEC 27002:2022 covers this ground in controls 5.30 (ICT readiness for business continuity), 8.13 (information backup) and 8.14 (redundancy of information processing facilities). Backups only support availability if restores are tested and at least one copy is offline or immutable, since ransomware targets backup catalogues first.

Availability differs from reliability (the probability of running without failure over a period) and from resilience (the ability to keep delivering a degraded service and recover). It is lost through hardware faults, capacity exhaustion, software bugs, failed changes, DoS attacks and ransomware alike, which is why IT operations, not only security, owns most of it. GDPR Art. 32(1)(b) and (c) require the ability to ensure the ongoing availability and resilience of processing systems and to restore access to personal data in a timely manner, so a prolonged loss of access can itself be a personal data breach. Availability often competes with confidentiality: aggressive account lockout, strict MFA or encryption with poorly escrowed keys can deny legitimate users access.