Recovery plan procedures supporting system recovery are tested to meet availability objectives.
Also written as A 1.3, TSC A1.3, SOC2 A1.3, SOC 2 Type 2 A1.3.
Recovery plan testing is one of 3 criteria in the Availability (A1) series of the Availability category. Recovery plan procedures supporting system recovery are tested to meet availability objectives. Because this sits outside the Common Criteria, it is only tested when Availability is in the scope of your engagement — check your report scope before building evidence for it.
When preparing for a SOC 2 audit against A1.3, gather artefacts such as:
A1.3 corresponds to the following ISO 27001:2022 Annex A control(s): A.5.30, A.8.13. If you already run an ISO 27001 ISMS, map your existing evidence for these controls to A1.3 rather than duplicating work.
Only if the Availability category is in scope. The Common Criteria (CC1–CC9) are mandatory for every SOC 2, but A1 criteria are tested only when you elect to include Availability in the engagement. Scope is your choice, usually driven by customer contracts.
In a Type 1 report the auditor assesses design only — does a control exist at a point in time that would meet A1.3 if it operated. In a Type 2 report they also test operating effectiveness by sampling evidence from across the review period, typically 3 to 12 months. That difference is why Type 2 evidence has to be continuous rather than assembled the week before fieldwork.
A control that fails becomes an exception, which the auditor describes in the report along with management's response. Exceptions do not automatically make a report "failed" — a SOC 2 report is an opinion, not a pass/fail certificate — but a qualified opinion is what customers notice, so remediate and re-test before fieldwork closes where you can.
Yes — A1.3 aligns with ISO 27001:2022 Annex A control(s) A.5.30, A.8.13. If you already run a certified ISMS, re-point that evidence rather than building a parallel set; the underlying control is the same and only the reporting format differs.