Audit recovery against complete criteria | CISA: audit IT, controls, and resilience

The outcome to recover

Start with the business function and agreed recovery criterion. If close depends on an application, keys, a partner and data validation, starting a VM does not demonstrate process recovery. Partial testing can be useful when its scope is explicit. This lesson’s practice contains five synthetic records, R1 through R5. All show elapsed time below the 45-minute RTO, but only R1 jointly meets the recorded criteria. The difference teaches assessment of the conclusion rather than simply accepting the execution report’s status color.

Time and data loss are different dimensions

R3 records 44 minutes of recovery and a seven-minute data gap against a 45-minute RTO and five-minute RPO. Time meets the stated objective, but the gap exceeds its limit. Do not subtract the one-minute RTO margin from RPO: the measures have different origins and meanings. In a real audit, verify how start, finish and data point were defined, including acceptance and reconciliation. A duration measured only to technical startup may be incompatible with an RTO defined through business acceptance.

Unknown data is not success

R5 has no data-gap value. In SQL, comparison with NULL does not positively confirm compliance. NOT(data_gap > rpo) does not mean “all cases without known failure” either: an unknown result is not selected by WHERE. Keep an explicit query for null fields and report unknown status separately from pass and fail. Replacing NULL with zero invents absence of loss. COUNT(data_gap) returns four known values while the table contains five exercises. The denominator should answer the audit question rather than be selected for a function’s convenient behavior.

Dependencies and acceptance evidence

R2 shows 20 minutes but the required key is unavailable and acceptance is absent. R4 shows 35 minutes, but partner connectivity and acceptance were not validated. These records do not demonstrate full recovery despite favorable timing. Investigate whether dependencies were deliberately excluded, failed or lacked collected evidence. Each situation supports a different conclusion. An honest report may state “technical startup demonstrated; complete process not tested.” This does not require production impact for every test; it requires a method appropriate to the intended conclusion.

Exercise and follow-up plan

Compare the query selecting only elapsed <= rto with the complete query below. The first returns R1 through R5; the second returns R1. Prepare a different request for R2, R3, R4 and R5: ability to use the key, treatment of the excessive RPO gap, external dependency validation and determination of the data point. Specify who responds and what evidence closes each item. A new ticket or promised date does not establish remediation. Follow-up ends with evidence proportionate to the observation, retaining limitations when testing remains partial.

SELECT id FROM recovery WHERE elapsed<=rto ORDER BY id;
SELECT id FROM recovery
WHERE elapsed<=rto AND data_gap<=rpo
 AND key_available=1 AND partner_validated=1 AND business_accepted=1
ORDER BY id;
SELECT id FROM recovery WHERE data_gap IS NULL;
SELECT COUNT(*),COUNT(data_gap) FROM recovery

IN PRACTICE

Five rehearsals meet the timing condition alone; only one meets every recorded condition. The auditor communicates the four limitations separately.

Common pitfalls

RTO as RPO; NULL as zero; startup time as accepted recovery; excluded partners as full testing; an opened ticket as completed remediation.

Related topics: RTO and RPO · Dependencies and acceptance

Take this idea with you

Recoverability needs a conclusion by criterion and scope. An aggregate metric should not hide dependencies or unknown data.

Create account

Reference: Assessing Security and Privacy Controls in Information Systems and Organizations · CISA outline effective August 1, 2024