Category: Business Continuity

Availability Requirements

Also known as: Availability Targets, Availability Objectives

Simply put

Availability requirements specify how accessible and operational a system or service must be when users need it, usually expressed as a target percentage of uptime over a defined period. These targets are commonly tied to a service level agreement (SLA) that sets an agreed minimum level of availability and performance. In practice, the specific target and how it is measured vary depending on the system, the business need, and the agreement in place.

Formal definition

Availability requirements define measurable conditions under which a system, application, or service must remain accessible and operational when required. They are typically stated as a target availability percentage over a specified time period, often derived from a service level agreement, and may incorporate a defined minimum uptime and performance threshold below which the system is considered to have failed. Availability itself can be framed as the probability that a system performs as required at the time it is needed over a defined mission or operating window. In a SOC 2 context, availability is addressed under the optional Availability Trust Services Criteria category (in addition to the required Security/Common Criteria) and is included only when selected during scoping; the specific commitments and thresholds depend on the service commitments and system requirements defined for the engagement rather than on any fixed universal value.

Why it matters

Availability requirements translate a business need for accessible, operational systems into a measurable commitment, typically expressed as a target uptime percentage over a defined period. Without a stated target, expectations between a service provider and its customers remain ambiguous, and it becomes difficult to determine whether a system has actually met its obligations. Because these requirements are commonly tied to a service level agreement, they also carry contractual and sometimes financial consequences when the agreed minimum uptime or performance threshold is not met.

In a SOC 2 context, availability matters specifically when the Availability Trust Services Criteria category is selected during scoping. Availability is an optional category in addition to the required Security (Common Criteria) category, so it is examined only when the service commitments and system requirements defined for the engagement call for it. When it is in scope, the availability commitments and thresholds documented for the engagement become the benchmark against which the auditor evaluates whether controls are suitably designed and, in a Type II examination, operating effectively over the review period.

It is important to recognize the boundary of what an availability requirement establishes: it defines a target and how failure is measured, but meeting a stated availability percentage does not by itself guarantee freedom from outages, breaches, or other disruptions outside the defined measurement. The specific target and measurement approach vary depending on the system, the business need, and the agreement in place, so the requirement is meaningful only in relation to the commitments it references.

Who it's relevant to

Compliance and GRC Managers

Those overseeing a SOC 2 program need to determine whether the Availability category should be included in scope, and if so, ensure that the service commitments and system requirements clearly document the availability targets and how they are measured. Because availability is optional in addition to the required Security criteria, the decision to include it should reflect actual business and customer needs.

SOC 2 Auditors

Practitioners evaluating an engagement where the Availability category is in scope assess whether controls are suitably designed and, in a Type II examination, operating effectively over the review period against the availability commitments defined for the engagement. The relevant benchmark is the documented service commitments and system requirements rather than any universal uptime figure.

Security and Reliability Engineers

Engineers responsible for keeping systems accessible and operational translate availability targets into technical measures and monitoring. They must understand how the agreed minimum uptime and performance thresholds are defined and how failure is measured so that operations can be aligned to the stated requirement.

Contract and Vendor Managers

Because availability requirements are commonly tied to a service level agreement, those negotiating or managing agreements need to understand what target percentage, measurement period, and performance thresholds are being committed to, and what constitutes failure under the agreement in place.

Inside Availability Requirements

Availability Trust Services Category

In SOC 2, availability is one of the optional Trust Services Criteria categories, selected in addition to the required Security (Common Criteria) category based on scoping decisions. It addresses whether systems are available for operation and use as committed or agreed.

Service Commitments and System Requirements

Availability requirements typically reference the commitments an organization makes to customers (for example, in service level agreements) and the internal system requirements needed to meet those commitments. The specific commitments vary by engagement and scope.

Capacity and Performance Monitoring

Controls in this area commonly address monitoring of system capacity, performance, and utilization to help ensure resources are sufficient to meet availability commitments, though the exact controls depend on the auditor and scope.

Backup, Recovery, and Resilience

Availability requirements often encompass backup processes, disaster recovery, and business continuity measures intended to restore service after disruption. The design and operating effectiveness of these controls are what a SOC 2 examination evaluates when availability is in scope.

Relationship to ISO 27001

Availability is one component of information security under ISO 27001, where it may be addressed through the ISMS and Annex A reference controls selected via the Statement of Applicability. Mapping between SOC 2 availability criteria and ISO 27001 controls is possible but partial.

Common questions

Answers to the questions practitioners most commonly ask about Availability Requirements.

Is the Availability category required for every SOC 2 report?

No. Availability is one of the optional Trust Services Criteria categories, selected based on the scope of the engagement. Only Security (the Common Criteria) is required in a SOC 2 examination. Availability, Processing Integrity, Confidentiality, and Privacy are included at the discretion of the scoping decisions made for the engagement, so whether Availability applies depends on the criteria selected.

Do the SOC 2 Availability criteria map directly to ISO 27001 Annex A controls?

Not directly. The Availability category is part of the Trust Services Criteria used in a SOC 2 attestation examination and should not be conflated with ISO 27001 Annex A reference controls. While some concepts may partially overlap, the two frameworks are structured differently, and mapping between them is partial. Satisfying the Availability criteria in a SOC 2 report does not automatically satisfy any corresponding ISO 27001 requirement, and vice versa.

How do we decide whether to include the Availability category in our SOC 2 scope?

The decision typically depends on the commitments you make to customers and the nature of the services you provide. In most engagements, organizations that make service availability or uptime commitments consider including this category. The final scope is set through scoping discussions with your service auditor and reflects the criteria relevant to your service commitments and system requirements, rather than a universal rule.

What kinds of controls are typically evaluated under the Availability category?

Controls addressed under the Availability category typically relate to how the organization maintains, monitors, and recovers the availability of its systems in line with its commitments. The specific controls depend on scope and on the auditor's assessment, so there is no fixed mandatory list. The examination evaluates the controls the organization has defined against the applicable criteria rather than prescribing particular measures.

Does an Availability assessment differ between a SOC 2 Type I and a Type II report?

Yes. In a Type I report, the Availability-related controls are assessed for suitability of design at a point in time. In a Type II report, those controls are assessed for both design and operating effectiveness over a defined review period, the length of which varies and is set by scoping decisions. So a Type II provides evidence about how the controls operated over time, whereas a Type I addresses design at a single moment.

If our report covers the Availability category, does that guarantee our systems will not experience downtime?

No. A SOC 2 report attests only to the controls and the period covered and does not guarantee freedom from outages or breaches. Including the Availability category means the relevant controls were examined against the applicable criteria, but it does not warrant uninterrupted service. The report reflects the controls in scope during the covered period rather than a promise of continuous availability.

Common misconceptions

Availability is a mandatory part of every SOC 2 report.

Only the Security category (Common Criteria) is required in a SOC 2 examination. Availability is an optional category selected based on scope, so many SOC 2 reports do not include it.

A SOC 2 report covering availability guarantees uptime or freedom from outages.

A SOC 2 report attests only to the suitability of design (Type I) or the design and operating effectiveness (Type II) of the controls over the covered period. It does not guarantee that outages will not occur or that availability commitments are always met.

Meeting SOC 2 availability criteria automatically satisfies ISO 27001 availability-related requirements.

Satisfying one framework does not automatically satisfy the other. Mapping between SOC 2 Trust Services Criteria and ISO 27001 requirements and Annex A controls is partial, and each framework has its own scope, evidence, and evaluation approach.

Best practices

Confirm during scoping whether availability should be included as a Trust Services category, since it is optional and its inclusion depends on customer commitments and business needs.

Document the specific service commitments and system requirements that define your availability obligations, as these anchor the controls an auditor will evaluate.

For a Type II examination, ensure availability controls operate consistently throughout the defined review period, since the period length is set by scoping decisions and effectiveness is assessed over time.

Implement and evidence capacity monitoring, backup, and recovery processes appropriate to your committed availability, recognizing that specific controls vary by engagement.

If pursuing both SOC 2 and ISO 27001, map availability controls across frameworks deliberately rather than assuming equivalence, and document where coverage differs.

Communicate clearly to stakeholders that a SOC 2 report covers only the controls and period examined and does not guarantee uninterrupted service.