06 Availability

The Availability Trust Services category focuses on whether systems are available for operation and use as committed or agreed.

Availability does not simply mean:

The system is online.

A stronger availability program asks:

What availability did we promise?
      ↓
What infrastructure supports it?
      ↓
What could cause disruption?
      ↓
How do we detect failure?
      ↓
How do we recover?
      ↓
Can we prove recovery works?

For SOC 2, Availability is especially relevant for services where downtime can materially affect customers.

Examples include:

Cloud Platforms

SaaS Applications

Payment Platforms

Healthcare Systems

Identity Providers

Security Services

Customer-Facing Applications

The category may include controls supporting:

Service availability.
Capacity.
redundancy.
backup.
disaster recovery.
monitoring.
incident management.
environmental protections.
recovery testing.

Learning Objectives

By the end of this lesson, you will be able to:

Explain the SOC 2 Availability category.
Understand availability commitments.
Distinguish availability from security.
Understand SLA and availability objectives.
Build capacity-management controls.
Understand resilience and redundancy.
Govern single points of failure.
Build availability-monitoring controls.
Define backup controls.
Understand RTO and RPO.
Design disaster-recovery controls.
Understand business-continuity dependencies.
Test recovery procedures.
Manage availability incidents.
Assess third-party availability dependencies.
Define Availability evidence.
Test design and operating effectiveness.
Build practical SOC 2 Availability artifacts.

1. What Is Availability?

Availability concerns whether information and systems are available for operation and use according to the organization’s commitments and system requirements.

Conceptually:

Service Commitment
      ↓
Availability Requirement
      ↓
Architecture
      ↓
Monitoring
      ↓
Recovery
      ↓
Evidence

2. Availability Is Based on Commitments

The organization should first understand what it has promised.

Examples:

99.9% Uptime

24 × 7 Service

4-Hour Recovery

Daily Backup

Regional Resilience

These commitments may come from:

Customer Contracts

SLAs

Policies

Architecture Standards

Business Requirements

3. Availability vs Security

Security asks:

Is the system protected from unauthorized access and threats?

Availability asks:

Can authorized users access the system when required?

These overlap.

Example:

DDoS Attack
      ↓
Security Event
      +
Availability Impact

4. Availability vs Business Continuity

Availability often focuses on the service or system.

Business continuity is broader.

Availability
→ Can the technology service operate?

Business Continuity
→ Can the business continue critical operations?

The two should support one another.

5. Service Availability Requirements

For each critical service document:

Service

Business Criticality

Availability Requirement

RTO

RPO

Support Hours

Owner

6. Availability Commitment Example

Example:

Service:
CloudCRM

Availability Commitment:
99.9% monthly uptime

Controls should support that commitment.

7. SLA

A Service Level Agreement may define:

Availability Percentage

Support Response

Service Credits

Maintenance Windows

Exclusions

SOC 2 Availability assurance evaluates controls that support these commitments.

8. SLA Is Not an Availability Control by Itself

Important:

SLA
≠
Control

The SLA defines what should be achieved.

Controls help achieve it.

9. Availability Percentage

A service may define:

99.9%

But the organization should also define:

How measured?

What period?

Which components?

What exclusions?

10. Planned Maintenance

Availability measurement may exclude approved maintenance windows.

Example:

Monthly Maintenance Window:
Sunday 02:00–04:00

This should be defined and communicated.

11. System Criticality

Not every system requires the same availability.

Example:

System	Criticality	Target
Customer Portal	Critical	99.99%
Internal Wiki	Medium	99.5%
Test Environment	Low	Best Effort

12. Business Impact Analysis

Availability requirements should be informed by business impact.

Ask:

If this service stops:

What customer impact?

What financial impact?

What operational impact?

What regulatory impact?

13. BIA Output

A Business Impact Analysis may define:

Critical Services

Maximum Tolerable Downtime

RTO

RPO

Dependencies

14. Recovery Time Objective

RTO means:

Recovery Time Objective

It defines how quickly a system should be restored after disruption.

Example:

RTO:
4 Hours

15. RTO Example

Incident begins:

10:00

RTO:

4 Hours

Target recovery:

By 14:00

16. Recovery Point Objective

RPO means:

Recovery Point Objective

It defines the acceptable amount of data loss measured in time.

Example:

RPO:
1 Hour

17. RPO Example

Failure occurs:

16:00

RPO:

1 Hour

The organization should be able to recover data to approximately:

15:00

or later.

18. RTO vs RPO

RTO
→ How long can service be unavailable?

RPO
→ How much data can be lost?

Both should drive architecture and backup design.

19. Build RTO/RPO Register

Create:

01 RTO-RPO Register

Use:

Service	Criticality	RTO	RPO	Owner

20. Capacity Management

Availability can fail because the system lacks resources.

Examples:

CPU Exhaustion

Memory Exhaustion

Disk Capacity

Connection Limits

Database Capacity

Network Bandwidth

21. Capacity Monitoring

A basic model:

Resource Usage
      ↓
Threshold
      ↓
Alert
      ↓
Action

22. Capacity Control

Example:

Critical infrastructure capacity is monitored against defined thresholds, and alerts are investigated before resource exhaustion affects service availability.

23. Capacity Evidence

Examples:

Monitoring Dashboard

Capacity Alerts

Scaling Events

Capacity Reviews

24. Scaling

Modern platforms may support:

Auto Scaling

Load Balancing

Elastic Capacity

These can support Availability controls.

25. Capacity Forecasting

Organizations should also consider anticipated demand.

Examples:

Customer Growth

Seasonal Peaks

Product Launch

Marketing Campaign

Acquisition

26. Infrastructure Resilience

Resilience means designing systems to continue or recover when components fail.

A resilient design may include:

Redundancy

Failover

Multiple Zones

Multiple Regions

Backup

Alternative Connectivity

27. Single Point of Failure

A single point of failure exists when one component can disrupt the whole service.

Example:

Application
      ↓
Single Database Server

If the database fails:

Entire Service Fails

28. Identify Single Points of Failure

Review:

Compute

Database

Storage

Network

Identity

DNS

Cloud Region

Third Parties

29. Redundancy

Redundancy may include:

Multiple Servers

Multiple Network Paths

Replicated Databases

Multiple Availability Zones

30. High Availability Architecture

Example:

             Load Balancer
               /      \
              /        \
         App Zone A   App Zone B
              \        /
               \      /
           Replicated Database

This reduces dependency on one component.

31. Availability Zones

Cloud environments may distribute workloads across multiple availability zones.

Example:

Zone A
+
Zone B

If one zone fails:

Service Continues

if designed appropriately.

32. Multi-Region Architecture

For higher-criticality systems:

Primary Region
      ↓
Secondary Region

may support recovery from regional failure.

33. Multi-Region Does Not Automatically Mean Resilient

If both regions depend on:

One Identity Provider

One DNS Provider

One Database Dependency

significant concentration risk remains.

34. Dependency Mapping

For every critical service identify:

Application

Database

Network

Identity

Cloud Provider

DNS

CDN

SaaS Dependencies

35. Availability Dependency Map

Create:

02 Availability Dependency Map

Example:

Customer Portal
      ↓
DNS
      ↓
CDN
      ↓
Cloud Load Balancer
      ↓
Application
      ↓
Database
      ↓
Identity Provider

36. Availability Monitoring

Organizations should detect outages quickly.

Monitoring may include:

Application Health

Infrastructure Health

Network Health

Synthetic Tests

Transaction Monitoring

37. External Monitoring

Internal monitoring alone may miss certain failures.

Example:

Server Says:
Healthy

but:

Customers Cannot Reach Service

External synthetic monitoring can identify this.

38. Synthetic Monitoring

Example:

Every Minute
      ↓
Login
      ↓
Perform Test Transaction
      ↓
Measure Response

This validates customer-facing availability.

39. Availability Monitoring Control

Example:

Critical production services are continuously monitored for availability, performance, and infrastructure health, with defined escalation thresholds.

40. Availability Monitoring Evidence

Examples:

Uptime Reports

Health Checks

Synthetic Monitoring

Alert Records

Incident Tickets

41. Monitoring Coverage

Build:

Service	Availability Monitoring	Alerting	Owner

Every critical service should be represented.

42. Alert Thresholds

Examples:

Service Down

Error Rate >5%

Latency >2 Seconds

CPU >90%

Thresholds should align with service risk.

43. Alert Escalation

A basic workflow:

Alert
      ↓
On-Call Engineer
      ↓
Incident
      ↓
Escalation

44. 24×7 Services

If a service commitment is:

24 × 7

but support monitoring only operates:

09:00–17:00

there may be a control-design issue.

45. Incident Management

Availability incidents should follow a structured process.

Detect
      ↓
Triage
      ↓
Severity
      ↓
Restore Service
      ↓
Communicate
      ↓
Root Cause
      ↓
Corrective Action

46. Availability Incident Examples

Examples:

Database Outage

Cloud Region Failure

DNS Failure

Network Failure

Capacity Exhaustion

Deployment Failure

47. Incident Severity

Example:

SEV-1
Critical Service Unavailable

SEV-2
Major Degradation

SEV-3
Limited Impact

48. Availability Incident Control

Critical service disruptions are documented, prioritized, escalated, restored, and reviewed according to the incident-management process.

49. Mean Time to Detect

MTTD measures:

Failure
      ↓
Detection

50. Mean Time to Restore

MTTR may measure:

Incident Begins
      ↓
Service Restored

depending on organizational definition.

51. Availability Metrics

Useful metrics include:

Uptime

MTTD

MTTR

Number of Major Incidents

SLA Breaches

Recovery Success

52. Backup

Backup is a key Availability control.

But:

Backup Exists
≠
System Can Recover

Backup is only one part of recovery assurance.

53. Backup Scope

Identify:

Databases

Object Storage

Virtual Machines

Configurations

SaaS Data

Critical Files

54. Backup Frequency

Examples:

Continuous

Hourly

Daily

Weekly

Frequency should support RPO.

55. RPO and Backup Frequency

If:

RPO = 1 Hour

but:

Backup = Once Per Day

the design does not support the objective.

56. Backup Retention

Define:

7 Days

30 Days

1 Year

based on requirements.

57. Backup Encryption

Backups may contain the same sensitive data as production.

Therefore controls may include:

Encryption

Access Restrictions

Logging

58. Backup Isolation

Ransomware risk may require:

Immutable Backups

Offline Copies

Separate Accounts

Restricted Credentials

59. Backup Failure Monitoring

A failed backup should generate:

Alert
      ↓
Investigation
      ↓
Correction

60. Backup Control

Example:

Critical systems and data are backed up according to defined schedules and retention requirements, and failed backup jobs are monitored and remediated.

61. Backup Evidence

Examples:

Backup Job Reports

Failure Alerts

Retention Configuration

Encryption Configuration

62. Restore Testing

A critical control is:

Can We Restore?

A backup can exist but be:

Corrupted

Incomplete

Misconfigured

Unavailable

63. Restore Test

Example:

Backup
      ↓
Restore to Test Environment
      ↓
Validate Data
      ↓
Validate Application

64. Restore Test Evidence

Include:

Test Date

System

Backup Used

Recovery Time

Data Recovered

Result

Issues

65. Build Backup Evidence Register

Create:

03 Backup Evidence Register

Use:

System	Backup	Frequency	Last Success	Restore Test

66. Disaster Recovery

Disaster Recovery focuses on restoring technology services after major disruption.

Scenarios may include:

Regional Cloud Failure

Data Center Failure

Ransomware

Major Network Failure

Storage Corruption

67. Disaster Recovery Plan

The plan should define:

Systems

Priority

Dependencies

RTO

RPO

Recovery Steps

Roles

Communication

68. DR Architecture

Example:

Primary Production Region
      ↓
Replication
      ↓
Recovery Region

69. Recovery Runbooks

Technical teams should know:

How to fail over?

How to restore?

How to validate?

How to fail back?

70. Disaster Recovery Testing

DR plans should be tested.

A test may include:

Tabletop

Partial Technical Recovery

Full Failover

Full Regional Recovery

71. Tabletop Exercise

A tabletop asks:

What would each team do if the primary region failed?

It tests:

Roles

Decision Making

Communication

Dependencies

but may not prove technical recovery.

72. Technical Recovery Test

A stronger test may:

Recover Database

Start Application

Validate Connectivity

Validate Customer Workflow

73. Full Failover Test

For mature environments:

Production / Controlled Environment
      ↓
Fail to Secondary Region
      ↓
Validate Service

This provides stronger assurance but carries operational risk.

74. Recovery Test Register

Create:

04 Disaster Recovery Test Register

Use:

Service	Test Type	Date	RTO	Actual	Result

75. Compare Actual Recovery to RTO

Example:

RTO:
4 Hours

Actual Recovery:
2 Hours 45 Minutes

Result:
Pass

76. Recovery Failure

Example:

RTO:
2 Hours

Actual:
6 Hours

Result:

Control Gap

77. Compare Recovered Data to RPO

Example:

RPO:
30 Minutes

Recovered Data Loss:
15 Minutes

Pass

78. Recovery Test Findings

Common issues include:

Outdated Runbook

Missing Credentials

Broken Replication

DNS Failure

Unknown Dependency

Insufficient Capacity

79. Post-Test Review

After each major test:

Test
      ↓
Findings
      ↓
Root Cause
      ↓
Corrective Action
      ↓
Retest

80. DR Control

Example:

Disaster-recovery capabilities for critical systems are periodically tested against established recovery objectives, and deficiencies are tracked to remediation.

81. Business Continuity Dependencies

A technically recovered system may still be unusable if:

Employees Cannot Work

Identity Is Unavailable

Critical Supplier Is Down

Communication Channels Fail

Availability planning should understand these dependencies.

82. People Dependencies

Ask:

Who performs recovery?

Are they available 24×7?

Is knowledge concentrated in one person?

83. Documentation Dependencies

Recovery should not rely only on:

One Engineer Remembers How

Use documented runbooks.

84. Credential Dependencies

Recovery credentials should be:

Available

Protected

Tested

85. Third-Party Availability

Critical services may depend on vendors.

Examples:

Cloud Provider

DNS

CDN

Identity Provider

Payment Provider

Monitoring SaaS

86. Provider Assurance

For critical providers review:

SOC 2 Availability Scope

SLA

Resilience Architecture

Incident History

DR Commitments

87. Provider Availability Is Not Your Availability

Important:

Cloud Provider Available

does not guarantee:

Your Application Available

Customer architecture still matters.

88. Example

Provider offers:

99.99% Infrastructure Availability

Customer deploys:

Single Instance
Single Zone

Customer architecture may remain fragile.

89. Availability Shared Responsibility

Provider may own:

Physical Infrastructure

Platform Availability

Customer may own:

Application Architecture

Failover

Backup Configuration

Recovery Testing

90. SaaS Availability

For SaaS providers assess:

Availability Commitment

Historical Outages

Provider Monitoring

Backup

Recovery

Customer Communication

91. SaaS Customer Responsibilities

Customer may still need:

Data Export

Alternative Business Process

Manual Workaround

Exit Strategy

for critical SaaS.

92. Availability Risk Register

Typical risks include:

Cloud Region Outage

Database Failure

Capacity Exhaustion

DNS Failure

Ransomware

Backup Failure

Provider Outage

Recovery Failure

93. Risk-to-Control Mapping

Example:

Risk:
Regional Cloud Failure
      ↓
Controls:
Multi-Region Recovery
Backups
DR Test
Incident Response

94. Availability Control Matrix

Create:

05 Availability Control Matrix

Use:

Control ID	Risk	Control	Owner	Evidence

95. Example Availability Controls

AVL-001
Availability Commitments

AVL-002
Service Monitoring

AVL-003
Capacity Monitoring

AVL-004
Infrastructure Resilience

AVL-005
Backup

AVL-006
Backup Failure Monitoring

AVL-007
Restore Testing

AVL-008
Disaster Recovery

AVL-009
Recovery Testing

AVL-010
Availability Incident Management

96. Availability Evidence Matrix

Create:

06 Availability Evidence Matrix

Use:

Control	Evidence	Frequency	Source	Owner

97. Evidence — Availability Monitoring

Examples:

Uptime Reports

Synthetic Monitoring

Alerts

Incident Tickets

98. Evidence — Capacity

Examples:

Resource Dashboard

Threshold Alerts

Capacity Review

Scaling Records

99. Evidence — Backup

Examples:

Backup Reports

Failure Logs

Retention Settings

Encryption

100. Evidence — Recovery

Examples:

DR Test

Restore Test

RTO/RPO Results

Corrective Actions

101. Availability Control Testing

For each control define:

Requirement

Population

Evidence

Test

Exceptions

Conclusion

102. Test Availability Monitoring

Population:

Critical Production Services

Verify:

Monitoring Enabled?

Alerting Enabled?

Owner Defined?

103. Test Backup

Population:

Critical Systems

Verify:

Backup Enabled

Correct Frequency

Retention

Encryption

Success

104. Test Restore

Sample restore tests.

Validate:

Completed?

Successful?

Within RTO?

Within RPO?

105. Test DR

For each critical service:

Required Test Frequency

Latest Test

Results

Findings

Remediation

106. Test Incident Response

Sample major availability incidents.

Trace:

Detection

Escalation

Restoration

Communication

Root Cause

Closure

107. Design Effectiveness

Ask:

If these controls operate as designed, will the organization reasonably meet its Availability commitments?

Example:

RTO:
1 Hour

Recovery Architecture:
Manual rebuild from backup
estimated at 12 hours

This is a design gap.

108. Operating Effectiveness

Ask:

Did the control operate throughout the period?

Example:

Monthly Backup Review

Jan ✓
Feb ✓
Mar ✗
Apr ✓

Result:

Partially Effective

109. Complete Population Testing

Technical evidence may allow testing of:

100% Backup Coverage

100% Monitoring Coverage

100% Replication Status

110. Sampling

Manual controls may require sampling:

Recovery Tests

Incident Reviews

Capacity Reviews

Provider Assessments

111. Availability Finding Example — Backup

The Backup Standard requires daily backups for all critical production databases. Two of twenty critical databases were not included in the automated backup policy during the examination period.

Risk:

Data Loss

Extended Recovery Time

112. Availability Finding Example — DR

The organization requires annual disaster-recovery testing for critical services. Three critical applications had not undergone recovery testing within the required period.

113. Availability Finding Example — Capacity

Capacity alerts were not configured for the primary production database despite recurring utilization above 90%.

114. Availability Finding Example — Single Point of Failure

The customer-facing application relies on a single production database instance without tested failover despite a four-hour recovery commitment.

115. Root Cause Analysis

Example:

DR Test Missing
      ↓
No Scheduled Test
      ↓
No Central Recovery Calendar

Root cause:

Disaster-recovery testing is managed independently by application teams without centralized governance or escalation.

116. Correction vs Corrective Action

Correction:

Perform overdue DR test.

Corrective action:

Implement centralized DR test scheduling
and escalation for all critical services.

117. Availability Exceptions

Example requirement:

Multi-Zone Deployment Required

Legacy platform:

Cannot Support It

Exception should include:

Risk

Compensating Controls

Owner

Approval

Expiry

Migration Plan

118. Possible Compensating Controls

Examples:

Frequent Backups

Warm Standby

Enhanced Monitoring

Reduced Recovery Time

Replacement Roadmap

119. Availability Dashboard

Useful metrics include:

Service Availability

SLA Compliance

Backup Coverage

Restore Test Completion

DR Test Completion

RTO Achievement

RPO Achievement

Major Incidents

120. Example Availability Dashboard

Metric	Target	Current
Critical Service Monitoring	100%	100%
Backup Coverage	100%	98%
Restore Tests Current	100%	95%
DR Tests Current	100%	90%
RTO Tests Passed	100%	92%

121. Availability KPI

Example:

KPI:
Percentage of critical services
meeting defined availability objective

122. Availability KRI

Example:

KRI:
Number of critical services
without current recovery testing

Tolerance:

123. Backup KRI

Example:

Critical workloads
without successful backup
within required window

Tolerance:

124. Recovery KRI

Example:

Number of recovery tests
that exceed required RTO

125. Audit Walkthrough — Availability Monitoring

Auditor selects:

Critical SaaS Service

Trace:

Availability Requirement
      ↓
Monitoring
      ↓
Alerts
      ↓
Incidents
      ↓
Reports

126. Audit Walkthrough — Backup

Auditor selects:

Production Database

Verify:

Backup Schedule

Successful Jobs

Retention

Encryption

Restore Test

127. Audit Walkthrough — Disaster Recovery

Auditor selects:

Critical Application

Review:

RTO

RPO

Recovery Plan

Latest Test

Result

Findings

Remediation

128. Audit Walkthrough — Availability Incident

Select a major outage.

Trace:

Detection
      ↓
Escalation
      ↓
Recovery
      ↓
Customer Communication
      ↓
Root Cause
      ↓
Corrective Action

129. Common Availability Mistakes

Mistake 1 — Availability Equals Uptime Report

Supporting controls are ignored.

Mistake 2 — SLA Treated as a Control

An SLA is a commitment, not a control.

Mistake 3 — RTO/RPO Undefined

Recovery architecture has no measurable target.

Mistake 4 — Backup Equals Recovery

Backups may be unusable.

Mistake 5 — DR Plan Never Tested

Recovery remains theoretical.

Mistake 6 — Monitoring Covers Infrastructure Only

Application or customer experience failures may be missed.

Mistake 7 — Single Points of Failure Not Documented

Architecture risk remains hidden.

Mistake 8 — Provider SLA Equals Customer Resilience

Customer design may remain fragile.

Mistake 9 — Recovery Findings Not Remediated

The same failures appear every test.

Mistake 10 — Availability Scope Too Broad

Controls do not clearly map to specific service commitments.

130. Weak Availability Model

Cloud Provider SLA
      +
Daily Backup
      =
Assume Available

131. Strong Availability Model

Business Requirement
      ↓
Availability Commitment
      ↓
RTO / RPO
      ↓
Resilient Architecture
      ↓
Monitoring
      ↓
Backup
      ↓
Recovery
      ↓
Testing
      ↓
Incident Management
      ↓
Evidence

132. Practical Activity — Build Availability Control Matrix

Create:

01 Availability Control Matrix

Include at least 15 controls across:

Availability Commitments

Capacity

Monitoring

Resilience

Backup

Recovery

Incident Management

Third Parties

133. Practical Activity — Build RTO/RPO Register

Create:

02 RTO-RPO Register

Add at least ten fictional critical systems.

Use:

Service	Criticality	RTO	RPO	Owner

134. Practical Activity — Build Backup Evidence Register

Create:

03 Backup Evidence Register

Track:

System

Frequency

Retention

Latest Backup

Encryption

Last Restore Test

135. Practical Activity — Build Disaster Recovery Test Register

Create:

04 Disaster Recovery Test Register

Use:

Service	Test	RTO	Actual	RPO	Result

136. Practical Activity — Build Availability Monitoring Matrix

Create:

05 Availability Monitoring Matrix

Use:

Service	Monitor	Alert	Escalation	Owner

137. Practical Activity — Build Dependency Register

Create:

06 Availability Dependency Register

Include:

Identity Provider

DNS

Cloud Provider

Database

CDN

Network

Critical SaaS

138. Practical Activity — Build Availability Control Testing Checklist

Create:

07 Availability Control Testing Checklist

Test:

Service Monitoring

Capacity

Backup

Backup Failure Monitoring

Restore Testing

Disaster Recovery

RTO

RPO

Major Incident Management

139. Availability Readiness Checklist

Scope

Critical services identified.
Availability commitments documented.
System boundaries defined.
Owners identified.

RTO/RPO

RTO defined.
RPO defined.
Objectives approved.
Architecture aligns with objectives.

Capacity

Capacity monitored.
Thresholds defined.
Alerts configured.
Forecasting performed where appropriate.

Resilience

Single points of failure identified.
Redundancy implemented.
Failover defined.
Dependencies documented.

Monitoring

Critical services monitored.
External monitoring used where required.
Alerts defined.
Escalation established.
Uptime measured.

Backup

Critical data backed up.
Frequency supports RPO.
Retention defined.
Encryption implemented.
Failure alerts configured.

Recovery

Recovery plans documented.
Recovery runbooks current.
Restore testing performed.
DR testing performed.
RTO results recorded.
RPO results recorded.
Findings remediated.

Incidents

Availability incidents classified.
Escalation defined.
Customer communication defined.
Root cause performed.
Corrective actions tracked.

Third Parties

Critical providers identified.
Availability commitments reviewed.
Provider assurance reviewed.
Concentration risk considered.
Alternative arrangements considered where required.

140. GRC Analyst Responsibilities

A GRC professional supporting SOC 2 Availability may:

Identify in-scope services.
Document availability commitments.
Maintain RTO/RPO registers.
Map availability risks to controls.
Review architecture dependencies.
Maintain Availability control matrices.
Review backup evidence.
Review recovery testing.
Validate DR test frequency.
Review provider availability assurance.
Assess control design.
Test operating effectiveness.
Document findings.
Track remediation.
Maintain Availability KPIs and KRIs.
Support external SOC auditors.

GRC connects:

Business Owners

Engineering

Cloud

IT Operations

SRE

Security

Risk

Business Continuity

Vendors

Auditors

141. Availability Maturity Model

Level 1 — Reactive

Outage Occurs
      ↓
Team Responds

Level 2 — Defined

Backups

Monitoring

Recovery Plans

Level 3 — Risk Based

RTO

RPO

Criticality

Recovery Testing

Level 4 — Integrated

Resilience

Automated Monitoring

Metrics

Provider Assurance

Level 5 — Continuous Resilience Assurance

Continuous Availability Monitoring

Automated Recovery Validation

Dependency Monitoring

Dynamic Risk Signals

142. Availability Mindset

For every critical service ask:

What have we promised customers?

How critical is the service?

What is the RTO?

What is the RPO?

Which components could fail?

Which dependencies could fail?

How quickly would we detect failure?

Do we have sufficient capacity?

Are backups complete?

Can we restore them?

Can we recover the whole service?

When was recovery last tested?

Did the test meet RTO and RPO?

What happened during real outages?

Were root causes corrected?

Which providers do we depend on?

Can we prove all of this to an auditor?

When these questions can be answered, Availability becomes demonstrable operational resilience rather than simply an uptime percentage.

Key Takeaways

Availability evaluates whether systems are available for use according to commitments and requirements.
Availability commitments should be clearly defined before controls are designed.
SLAs express commitments but are not themselves availability controls.
System criticality should drive availability requirements.
RTO defines how quickly service must recover.
RPO defines acceptable data loss.
Capacity management helps prevent resource-exhaustion outages.
Resilient architectures reduce single points of failure.
Availability monitoring should include customer-facing service health where appropriate.
Backup success does not prove recoverability.
Restore and disaster-recovery testing are essential.
Recovery tests should be evaluated against RTO and RPO.
Availability incidents should be detected, escalated, restored, reviewed, and remediated.
Third-party dependencies and concentration risk are important Availability considerations.
Provider availability does not automatically guarantee application availability.
GRC connects Availability commitments to risks, controls, evidence, testing, findings, and assurance.

Knowledge Check

Before continuing, make sure you can answer:

What does the SOC 2 Availability category address?
Why should availability commitments be defined first?
How is an SLA different from a control?
What is RTO?
What is RPO?
How does backup frequency relate to RPO?
What is capacity management?
What is a single point of failure?
How does redundancy improve availability?
Why does multi-region architecture not automatically guarantee resilience?
What should availability monitoring include?
Why can external synthetic monitoring be useful?
Why does backup success not prove recovery?
What should a restore test validate?
What should a DR plan contain?
What is the difference between a tabletop and a technical recovery test?
Why should recovery results be compared with RTO and RPO?
How can third-party providers affect availability?
What evidence can support Availability controls?
What role does GRC play in SOC 2 Availability?

What’s Next?

➡️ Next: 07 — Processing Integrity

In the next lesson, you will move into the Processing Integrity Trust Services category and learn how organizations demonstrate that system processing is complete, valid, accurate, timely, and authorized.

You will work through:

Input Validation
      ↓
Transaction Authorization
      ↓
Processing Logic
      ↓
Completeness
      ↓
Accuracy
      ↓
Error Handling
      ↓
Reconciliation
      ↓
Output Validation
      ↓
Exception Management
      ↓
Evidence & Testing

You will also build practical artifacts including a Processing Integrity Control Matrix, Transaction Flow Map, Input/Output Control Register, Reconciliation Register, Processing Exception Register, and Processing Integrity Control Testing Checklist.