Skip to main content
Control Institute
Category: Business Continuity

High Availability

Also known as: HA, High Availability Architecture, HA system
Simply put

High availability refers to designing systems, applications, and services so they stay operational and accessible close to 100% of the time, even when individual components fail. The goal is to maintain an agreed level of performance, usually uptime, and to keep services running continuously for a designated period. In a compliance context, availability characteristics like these are typically relevant when the Availability category of the SOC 2 Trust Services Criteria is in scope.

Formal definition

High availability (HA) is a system characteristic aimed at ensuring an agreed level of operational performance, usually measured as uptime, for a higher-than-normal period, achieved through architectural design approaches that keep systems, applications, and services operational despite the failure of individual components. Practically, HA is realized through redundancy, failover, and continuous-operation design so a system runs without interruption for a designated period. Within security compliance, HA controls are most commonly assessed under the optional Availability category of the SOC 2 Trust Services Criteria (selected based on scope), and may support availability-related objectives within an ISO/IEC 27001 ISMS where in scope; note that HA is a design property and does not by itself guarantee any specific compliance outcome, which depends on the applicable criteria, scope, and the assessing auditor or certification body.

Why it matters

Availability is a core concern for organizations that deliver services their customers depend on, and high availability is the design discipline aimed at keeping those systems accessible and reliable close to 100% of the time. When individual components inevitably fail, an HA architecture is intended to absorb that failure without interrupting service, preserving the agreed level of operational performance, usually measured as uptime, that users and contractual commitments expect.

In a security compliance context, high availability becomes directly relevant when the optional Availability category of the SOC 2 Trust Services Criteria is included in scope. Because Availability is not one of the required criteria and is selected based on scoping decisions, HA controls are typically assessed only in engagements where a service organization has committed to availability-related objectives. HA characteristics may also support availability objectives within an ISO/IEC 27001 ISMS where such objectives are in scope. In both cases, the presence of an HA design is not sufficient on its own; the compliance outcome depends on the applicable criteria, the defined scope, and the judgment of the assessing auditor or certification body.

It is important to keep expectations grounded: high availability is a design property, not a guarantee. An HA architecture reduces the likelihood that a single component failure takes down a service, but it does not by itself assure any specific compliance result, nor does it eliminate all risk of downtime. Organizations should treat HA as one contributing element within a broader availability and resilience program rather than as a standalone compliance solution.

Who it's relevant to

Compliance and GRC Managers
For teams deciding whether to include the Availability category in a SOC 2 engagement, high availability defines the kind of architectural controls that would come under examination. Understanding HA helps in scoping decisions and in setting realistic availability commitments, while recognizing that HA alone does not determine the compliance outcome.
Auditors and Assessors
When the optional Availability category of the SOC 2 Trust Services Criteria is in scope, or when availability-related objectives fall within an ISO/IEC 27001 ISMS, assessors evaluate whether HA controls such as redundancy and failover are suitably designed and, in a SOC 2 Type II engagement, operating effectively over the review period. The assessment depends on the applicable criteria and scope.
Security and Infrastructure Engineers
Engineers responsible for system design implement HA through redundancy, failover, and continuous-operation architecture to keep systems operational despite individual component failures. Their work produces the technical evidence that supports availability objectives, though the resilience they build is one element of a broader availability program rather than a guarantee against downtime.

Inside HA

Redundancy
The duplication of critical components or systems, such as servers, network paths, or power supplies, so that the failure of any single element does not cause an interruption of service. Redundancy is a foundational element of high availability architectures.
Failover
The automated or manual process by which operations are transferred from a failed or degraded component to a standby component, typically with the goal of minimizing downtime. Failover mechanisms vary in speed and complexity depending on the design.
Load Balancing
The distribution of workloads across multiple resources to prevent any single resource from becoming a point of failure or a performance bottleneck, supporting continuous availability of the service.
Monitoring and Alerting
The ongoing observation of system health and performance, combined with notification mechanisms that allow personnel to detect and respond to degradation or failures. In most engagements this supports the demonstration that availability controls operate effectively over time.
Relationship to the Availability Trust Services Criterion
Within SOC 2, high availability practices are relevant when the Availability category is selected as part of the scope. Availability is one of the optional Trust Services Criteria categories (alongside Processing Integrity, Confidentiality, and Privacy) and is not required; only the Security category (the Common Criteria) is mandatory.
Relationship to ISO 27001
In an ISO/IEC 27001 ISMS, availability is one of the information security properties addressed through risk assessment and the selection of applicable reference controls via the Statement of Applicability. The specific controls chosen depend on scope, the identified risks, and the version of the standard in use.

Common questions

Answers to the questions practitioners most commonly ask about HA.

Does having high availability guarantee that I will pass the SOC 2 Availability criteria?
No. High availability is an architectural approach to reducing downtime, while the Availability category of the Trust Services Criteria is one of the optional categories a service organization may select in addition to the required Security (Common Criteria) category. Selecting Availability in scope means an auditor evaluates the controls you have in place to meet your availability commitments; a highly available architecture may support those controls, but the SOC 2 outcome depends on the design and, for a Type II, the operating effectiveness of the controls over the review period, not on the architecture alone. A SOC 2 report attests only to the controls and period covered and does not guarantee freedom from outages.
Is high availability a mandatory control under ISO 27001?
Not in the sense of an unconditional requirement. ISO 27001's certifiable requirements are in clauses 4 through 10, and Annex A provides reference controls that are selected through a Statement of Applicability informed by risk assessment. Whether controls related to availability or redundancy are included depends on your risk assessment and the defined scope of the ISMS. There is no blanket rule that a specific high-availability architecture must be implemented; the applicability and depth of any related control depend on scope and the risks you identify.
How does high availability relate to the SOC 2 Availability category if I choose to include it in scope?
Where Availability is selected as an in-scope category, the auditor examines the controls supporting your stated availability commitments and system requirements. High-availability techniques can serve as part of the control environment that supports those commitments. In most engagements the focus is on whether controls are suitably designed and, for a Type II, operating effectively over the defined period, rather than on any particular technology choice. The specifics depend on the scope and criteria agreed during the engagement.
How can I document high availability so it supports an ISO 27001 ISMS?
Typically, availability-related measures are tied back to the risk assessment and, where applicable, reflected in the Statement of Applicability with a justification for inclusion or exclusion of relevant Annex A reference controls. Note that Annex A was restructured in the 2022 revision, so the way controls are grouped and referenced depends on which edition you are working against. Documentation generally covers the rationale for the chosen approach relative to identified risks and the defined ISMS scope rather than prescribing a fixed technical standard.
What are the limitations of relying on high availability for compliance purposes?
High availability addresses continuity of service and reduction of downtime, but it does not by itself demonstrate compliance. A SOC 2 report attests only to the controls and period covered and does not guarantee an absence of outages or breaches, and an ISO 27001 certificate covers only the defined scope of the ISMS. Availability measures are one element among many, and their relevance depends on the auditor, certification body, scope, and applicable criteria.
If I address availability for SOC 2, does that satisfy any ISO 27001 requirements automatically?
Not automatically. Mapping between SOC 2 and ISO 27001 is possible but partial, and satisfying one framework does not automatically satisfy the other. SOC 2 is an attestation examination performed by a licensed CPA firm resulting in a report, while ISO 27001 is a certification issued by an accredited certification body against a management system standard. Availability considerations may inform both, but each is assessed against its own criteria and scope, so overlap should be validated rather than assumed.

Common misconceptions

High availability guarantees that a system will never experience downtime or a breach.
High availability aims to reduce the likelihood and duration of outages but does not guarantee freedom from downtime, failures, or security breaches. A SOC 2 report attests only to the controls and period covered and does not guarantee uninterrupted service, and an ISO 27001 certificate covers only the defined scope of the ISMS.
Addressing high availability is mandatory in a SOC 2 examination.
Availability-related controls are only in scope when the Availability category is selected. Security (the Common Criteria) is the only required Trust Services Criteria category; Availability, Processing Integrity, Confidentiality, and Privacy are optional and chosen based on scoping decisions.
High availability is assessed identically under SOC 2 and ISO 27001.
The two frameworks treat availability differently. SOC 2 evaluates it through the Availability Trust Services Criterion in an attestation examination, while ISO 27001 addresses availability through ISMS requirements and risk-driven control selection. Mapping between the frameworks is possible but partial, and satisfying one does not automatically satisfy the other.

Best practices

Define recovery and availability objectives based on business requirements and risk assessment, rather than assuming a single approach applies universally, since appropriate targets depend on scope and criticality.
Implement redundancy and failover for components identified as critical, and periodically test failover procedures to confirm they operate as designed.
Establish continuous monitoring and alerting so that degradation or failures are detected and responded to promptly; retain evidence of these activities to support a SOC 2 Type II examination of operating effectiveness over the review period.
Where the Availability category is in scope for SOC 2, ensure controls are both suitably designed and, for a Type II engagement, operating effectively across the defined period set by scoping decisions.
For an ISO 27001 ISMS, document the treatment of availability risks and reflect selected reference controls in the Statement of Applicability, specifying the version of the standard being applied.
Clearly document the boundaries of availability commitments, recognizing that a SOC 2 report covers only the stated controls and period and an ISO 27001 certificate covers only the defined ISMS scope.