The Availability criterion
The Availability criterion requires that the system is available for operation and use as committed or agreed upon in service level agreements (SLAs) or other contracts. It focuses on ensuring systems are resilient, monitored, and recoverable to meet defined uptime objectives.
What it means
In practice, this criterion moves beyond simple "uptime." It requires an organization to define exactly what availability looks like for their customers—such as 99.9% uptime—and implement the technical and operational safeguards necessary to maintain that standard.
The scope includes the entire infrastructure stack: hardware, software, network connectivity, and the human processes required to manage them. This means addressing both prevention (stopping outages before they happen) and recovery (getting back online quickly after a failure).
Availability also encompasses capacity management. An organization must ensure it has sufficient resources—such as CPU, memory, and disk space—to handle current and projected loads without degrading performance or causing system crashes.
How to meet it
- Implement real-time monitoring and alerting for critical systems to detect outages or performance degradation immediately.
- Establish a formal Backup Policy that defines the frequency of backups, retention periods, and encryption requirements.
- Develop and maintain a Disaster Recovery Plan (DRP) and Business Continuity Plan (BCP) detailing how to restore services after a catastrophic event.
- Conduct regular capacity planning reviews to ensure infrastructure can scale with user growth and data volume.
- Define clear Service Level Agreements (SLAs) for customers that specify expected uptime and maintenance windows.
- Implement redundancy for critical components, such as load balancers or multi-region cloud deployments, to eliminate single points of failure.
Evidence an auditor asks for
- Copies of signed SLAs or public status pages demonstrating the availability commitments made to users.
- Records of recent Disaster Recovery tests (e.g., tabletop exercises or failover tests) including results and remediation steps for any failures.
- Backup logs or reports proving that backups are running successfully according to the defined schedule.
- Screenshots or configurations of monitoring tools showing active alerts for system health, latency, and uptime.
- Evidence of capacity reviews, such as resource utilization reports from cloud providers (e.g., AWS CloudWatch or Azure Monitor).
Common pitfalls
- Creating a Disaster Recovery Plan but failing to test it annually; auditors view an untested plan as non-existent.
- Relying on "automatic" cloud backups without verifying that the data can actually be restored and is usable.
- Failing to document capacity thresholds, meaning the organization only reacts to outages rather than proactively scaling resources.
- Neglecting to track and report downtime against the commitments made in SLAs.