Availability
Make the required service accessible to authorized users when it is needed.
The idea
Availability concerns timely, reliable access to information and services. It depends on capacity, resilience, maintenance, dependencies, and recovery—not merely whether one machine is running. Define requirements through business impact and service needs. Security controls can affect availability, so changes should include operational checks and fallback planning. A protected but unusable service may still fail its purpose.
In practice
A clinic’s application depends on identity, network, database, and staffing. Recovery tests account for those dependencies rather than checking only the application server.
A common misunderstanding
Maximum uptime is not always a realistic requirement; the organization needs explicit objectives and tested capabilities.
Check your understanding
Why assess dependencies?
Think it through: A failure in a supporting service can make the main service unavailable even when its own components work.
Start with the service people need
A fictional clinic uses an appointment system during opening hours. Keeping its web server running is insufficient if staff cannot authenticate, the database is unreachable, or the network link has failed. Define availability around the usable service and its business timing rather than one machine's uptime statistic.
The requirement may differ across functions. Booking new appointments could tolerate a short interruption, while checking a patient's immediate schedule may need a workable fallback. Identify the effect of delay, the maximum tolerable interruption, and the information needed during recovery. These decisions guide capacity and resilience investments.
Redundancy is useful only when the alternatives avoid relevant shared failures. Two application servers relying on one identity service can both become unusable when that service fails. A backup is also different from a ready replacement: restoring it may take time and depend on credentials, infrastructure, and people who are unavailable during the same incident.
Run a dependency exercise
For the clinic example, list authentication, network, database, storage, messaging, and staff responsibilities. Choose one dependency to be unavailable and describe how the service degrades. Use a tabletop discussion rather than interrupting a real clinic. Identify which functions continue, which stop, and how staff know what to do.
Security changes deserve the same operational reasoning. A stricter access rule or certificate rotation can cause an outage when implemented incorrectly. Test the intended protection and the legitimate workflow, with a defined rollback where appropriate. Availability is strengthened when the organization understands its service dependencies, measures recovery under realistic conditions, and maintains clear decisions for degraded operation. A promising architecture diagram is only the beginning of that evidence.
Keep exploring
References & further reading
Original explanations, with primary references for deeper study.
NIST: An Introduction to Information Security