7.5 System Availability Measures, Mirroring & Replication
Key Takeaways
- Availability equals agreed service time less downtime, divided by agreed service time, so the reported percentage depends entirely on how agreed service time is defined and which maintenance windows the contract excludes.
- A 99.9% monthly availability commitment permits roughly 43 minutes of downtime per 30-day month, while 99.99% permits roughly four and a half minutes; each additional nine costs roughly an order of magnitude more.
- Synchronous replication delivers a recovery point objective of zero but constrains distance because every write waits for the secondary to confirm, while asynchronous replication frees distance at the cost of a recovery point equal to the replication lag.
- Replication is not backup: it faithfully propagates accidental deletion, corruption and ransomware encryption to the secondary within seconds, which is why a retained, immutable, tested backup is a separate and non-substitutable control.
- Availability criteria A1.1 through A1.3 are evaluated against the service organization's own availability service commitments, so an annual tabletop walkthrough may be a suitable recovery test against a seventy-two-hour objective and a design deficiency against a four-hour objective.
System Availability Measures, Mirroring & Replication
Quick Answer: Three Area I availability tasks close here. Recall measures of system availability, which the blueprint illustrates with agreed service time and downtime — the two terms in the availability formula. Explain the objectives of mirroring and replication, which are availability and recovery point, not backup. And detect deficiencies in design and deviations in operation of controls over a service organization's availability service commitments in a SOC 2 engagement.
1. Measuring System Availability
The Formula
Availability is expressed as a percentage of the time the service was usable within the period it was promised:
Agreed Service Time - Downtime
Availability = -------------------------------- x 100
Agreed Service Time
- Agreed service time (AST) is the period during which the service is contracted to be available — for example, 24 hours a day, 7 days a week, or 06:00 to 22:00 on business days. Agreed, scheduled maintenance windows are normally excluded from AST by contract, which means maintenance does not count against the availability figure.
- Downtime is the unplanned unavailability that occurs inside the agreed service time.
Where candidates lose the point: the same outage produces different reported availability depending on how AST is defined and what is excluded. A four-hour outage inside a 24x7 commitment is downtime. The same four hours inside an agreed maintenance window is not. This is why an auditor reads the service level agreement's exclusions before accepting an availability metric, and why a service organization that "met 99.9%" while customers experienced repeated outages is usually excluding generously rather than performing well.
The Nines
| Availability | Maximum Downtime per Year | per Month (30 days) | Typical Commitment |
|---|---|---|---|
| 99% ("two nines") | ~3 days 15 hours | ~7 hours 12 min | Internal non-critical tooling |
| 99.9% ("three nines") | ~8 hours 46 min | ~43 min | Standard commercial SaaS |
| 99.95% | ~4 hours 23 min | ~22 min | Business-critical SaaS |
| 99.99% ("four nines") | ~53 min | ~4 min 19 s | Payments, trading, core banking |
| 99.999% ("five nines") | ~5 min 15 s | ~26 s | Telecommunications switching |
Each additional nine is roughly an order of magnitude more expensive, which is why the correct audit question is never "why not five nines" but "does the committed level match what the business actually requires, and does the architecture support it?"
Related Measures
- Mean time between failures (MTBF) — average operating time between failures of a repairable system. Higher is better; it measures reliability.
- Mean time to repair / restore (MTTR) — average time to restore service after a failure. Lower is better; it measures responsiveness.
- Mean time to failure (MTTF) — average life of a non-repairable component.
- Availability can be expressed as
MTBF / (MTBF + MTTR), which makes the trade-off explicit: availability improves either by failing less often or by recovering faster, and recovering faster is usually the cheaper lever.
SLA, SLO and SLI
- A service level indicator (SLI) is the measurement itself — for example, the percentage of requests returning successfully.
- A service level objective (SLO) is the internal target for that indicator.
- A service level agreement (SLA) is the contractual commitment to the customer, with remedies, and it is normally set looser than the internal SLO so that the organization detects drift before it breaches a contract.
An SLA credit is a refund, not a recovery. A service credit worth a fraction of a monthly fee does not compensate a user entity for a failed financial close. Auditors evaluating availability commitments look at the architecture and the tested recovery capability, not at the penalty clause.
2. Mirroring and Replication: What They Are For
The blueprint asks for the objectives of mirroring and replication, so lead with the objective: both exist to keep a current copy of data available so that a failure of one component or one site does not cause an outage or data loss. Neither exists to provide historical recoverability — that is what backup is for.
Mirroring
Writing the same data to two or more storage devices simultaneously so that either copy can serve requests.
- RAID 1 is the canonical form: two drives hold identical data; a drive failure is transparent to the application.
- Database mirroring maintains a continuously synchronized standby copy of a database.
- Objective: eliminate a single component as a point of failure and allow failover without data loss.
- Limit: mirroring inside one array, one server or one data center protects against component failure, not against loss of the site.
Replication
Copying data from a primary system to one or more secondary systems, usually at a distance.
| Synchronous replication | Asynchronous replication | |
|---|---|---|
| Commit rule | The write is acknowledged to the application only after the secondary confirms it | The write is acknowledged immediately; the secondary catches up |
| Recovery point objective | Zero — no committed transaction is lost | Greater than zero — the replication lag is the exposure |
| Distance | Constrained; latency grows with distance and slows every transaction | Effectively unconstrained; a continent away is fine |
| Failure behavior | If the link degrades, production slows or stalls | If the link degrades, the copy simply falls further behind |
| Typical use | Two data centers in one metropolitan area for a core ledger | Cross-region disaster recovery |
Active-passive keeps the secondary idle until failover. Active-active runs both sites live behind a load balancer, which delivers near-zero recovery time at the cost of managing write conflicts and data consistency across sites.
The Distinction That Gets Tested
Replication is not backup. Replication faithfully propagates whatever happens to the primary — including an accidental mass deletion, a corrupted table, and a ransomware encryption pass. Within seconds, the secondary is just as ruined as the primary. A backup is a point-in-time copy retained for a defined period, from which an earlier, uncorrupted state can be restored.
The three serve different objectives and an organization needs all three:
| Capability | Objective It Serves | Protects Against |
|---|---|---|
| Mirroring | Continuous availability of a component | Drive or server failure |
| Replication | Site-level availability and a low recovery point objective | Loss of a data center or region |
| Backup (retained, immutable, tested) | Recoverability to a prior point in time | Corruption, deletion, ransomware, and the need to produce historical data |
3. Where Business Resiliency Sits
The blueprint pairs three terms, and only one of them is new here. Section 7.2 develops business continuity planning (keeping essential business functions running — people, facilities, manual workarounds, crisis communication, supply chain) and disaster recovery planning (the technical subset that restores IT infrastructure, systems and data).
Business resiliency is the term that sits above both: the organization's overall ability to anticipate, absorb, adapt to and recover from disruption while continuing to deliver on its commitments. It is a strategic posture rather than a document — encompassing architectural redundancy, supplier diversity, financial reserves and organizational agility — and it operates before, during and after an event rather than being invoked when one occurs.
Key considerations common to all three: they must be grounded in a current business impact analysis; they must be documented, distributed and accessible when the primary systems are down; they must name specific people and alternates with current contact details; they must be tested, with results and remediation tracked; and they must be reviewed after every material change to the business or its technology.
4. Detecting Availability Deficiencies in a SOC 2 Engagement
The Availability category adds three criteria to the Common Criteria. A service auditor evaluates whether the organization's controls achieve them in light of its own availability service commitments and system requirements.
| Criterion | Control Objective | Design Deficiency Looks Like | Operating Deviation Looks Like |
|---|---|---|---|
| A1.1 Capacity | Current processing capacity and use are maintained, monitored and evaluated to meet commitments | No capacity monitoring exists, or thresholds are set above the point at which service degrades | Monitoring exists and alerted, but the two capacity reviews scheduled for the period were never performed |
| A1.2 Environmental protections and recovery infrastructure | Environmental protections, software, data backup processes and recovery infrastructure are authorized, designed, developed, implemented, operated, approved, maintained and monitored | Backups are configured for the application server but not for the database holding customer data | Generator load tests were performed in two of four quarters; one uninterruptible power supply battery was past end of life |
| A1.3 Recovery testing | Recovery plan procedures supporting system recovery are tested | The plan has no test requirement, or the test is defined as a document read-through against a four-hour recovery commitment | An annual failover test was scheduled and documented but was cancelled and never rescheduled |
Worked Example
A service organization commits to 99.9% monthly availability and a four-hour recovery time objective. Its documented recovery control is an annual tabletop walkthrough of the disaster recovery plan, performed on schedule for three consecutive years with no exceptions.
- Design evaluation first. A tabletop discussion produces no evidence that systems can actually be restored, and certainly not that they can be restored within four hours. The control, performed perfectly, cannot demonstrate achievement of the commitment. This is a deficiency in the suitability of design, and consistent performance is irrelevant.
- Operating effectiveness is not reached. The auditor does not test whether a deficient control operated consistently.
- The finding is anchored to the commitment. Had the organization committed to a seventy-two-hour recovery objective with a documented manual workaround, the same tabletop exercise might well have been suitable. The criterion is identical; the commitment changes the conclusion.
The general rule: in the Availability category more than any other, the service organization's own commitment supplies the yardstick. Read the commitment first, then ask whether the control could ever meet it, and only then ask whether it did.
A hosting provider replicates its production database synchronously to a second data center 15 kilometers away and cites this as its protection against data loss. During an incident, a database administrator executes an erroneous mass delete statement against the production database. What happens, and what control was missing?
A service organization reports 99.95% availability for the quarter. Its customers, however, documented three separate multi-hour interruptions during the same period. Which explanation is the auditor most likely to find when reconciling these facts?
A service organization commits to a four-hour recovery time objective. Its documented recovery control is an annual tabletop walkthrough of the disaster recovery plan, which has been performed on schedule and documented for three consecutive years with no exceptions noted. How should the service auditor evaluate this control under Availability criterion A1.3?