SOC 2 disaster recovery test evidence is the pack an auditor pulls when they sample the continuity control: a failover test ran, a named person ran it, it had a start and an end, and someone wrote what was observed. A dashboard that looked healthy on a quiet afternoon is not that pack. A backup vault that exists is not that pack either. The client is the one in the audit. Rutagon builds the evidence pipeline that files the test into the GRC platform you already run.
Recovery-point restore tests are a different artifact. We file those through AWS Backup restore testing. This article does not design a second region, a standby shape, or a restore workflow. It is the failover-test record: the service was handed to the path your continuity procedure already names, and the outcome was written down in a form a sample can open.
What counts as a failover test
The population is failover tests inside the audit window, not every incident and not every backup job. A test has an operator, a start, an end, and an observation about the service your procedure names. A conversation that never recorded those fields is not in the population yet. It becomes a test when the fields exist. Until then the row stays open as a missing test, which is the honest status if the procedure says a test was due.
Some teams run the drill as a timed runbook: a person starts a clock, follows the steps you already approved, and writes the observation in a ticket. Some teams run it as an experiment on AWS. AWS Fault Injection Service describes an experiment template as actions, targets, and stop conditions, and it describes a stop condition as a CloudWatch alarm that stops the experiment if a threshold is hit. An experiment is complete when its actions have run. That model is documented in What is AWS Fault Injection Service. When the drill is an experiment, we store the identifier and the status the service returns. We do not treat a stop condition firing as "no test." It is a completed run with an observation that the guardrail tripped. The reviewer can still call the outcome a failure. The record exists either way.
A tabletop uses the same fields. The observation has to say what decision was made and what would have been failed over. A sentence that only says "successful" is sent back. The reviewer needs a concrete result: the standby accepted work, or it did not, or the test stopped because a guardrail fired.
SOC 2 disaster recovery test evidence we file
Each test is one record:
- Test id, from the ticket or from the experiment identifier the service returns
- Operator, a workforce id, not a shared mailbox
- Start and end, taken from the system that ran the test or from the ticket timestamps if the test was a runbook
- Whether a stop condition fired
- The observation, in language a reviewer can check against the procedure
- The GRC ticket id once the pack is filed
test_id: failover-drill
operator: workforce-id
started_at: service-or-ticket-time
ended_at: service-or-ticket-time
stop_condition: not-fired
observed: standby-accepted-work
grc_ticket: required
The clock is the service clock or the ticket clock. A screenshot filename is not a timestamp. We have seen packs named with a month and no start or end inside the file. The sample then cannot tell whether the test fell inside the window. Start and end close that gap.
The observation is attached to the procedure step it corresponds to, by name, not by a pasted copy of the whole runbook. The runbook can change later. The test record should still point at the step that was exercised. If the procedure has no named step, the test record stays open until the procedure names one. We will not invent a procedure in the evidence file.
What this pack refuses to be
It is not a restore-test architecture. Selecting recovery points, inferring restore metadata, and proving a recovery-time number from a restore job are the other insight. Linking that pack into the GRC is correct. Copying its design into this record is how the two controls get blurred and the auditor asks for a failover that nobody ran.
It is not a steady-state screenshot. CPU on a graph, a green health check, or a replica lag of zero on an ordinary day does not show that anyone failed anything over. If the test did not change which path served traffic, or did not execute the decision the tabletop claims, the observation has to say that. Calling it a failover because the word appears in the ticket title is how the sample goes badly.
It is not an incident. Incidents have their own chain from detection through close. A failover that happens during an incident can be referenced from the incident ticket. The test pack is still for tests you scheduled. Using an outage as the only "test" in the window is a gap the continuity owner has to explain. We will file the outage on the incident record and leave the test row open if no test was run.
Freshness matters. A pack from a prior window does not satisfy this window. SOC 2 evidence freshness is how we keep a stale drill from being reattached because the file was handy. The collector writes collected_at from the test's end time. If that end sits outside the window, the item is not offered as the sample.
Filing and the empty window
The record is uploaded to the continuity control you already named in the GRC you already run. The ticket id comes back onto the record. When the GRC cannot store the fields, we attach the same structure and keep the ticket id. The next window is the same shape.
If the window contains no test, the evidence is an explicit empty population: the procedure's required cadence, the window, and the statement that no test id exists. We do not substitute a restore-test report to fill the hole. The owner either runs the failover test or documents the exception in the GRC. Silence is an open row.
This collector is part of the security automation we build behind the GRC you already run. The failover mechanism stays the one your engineers already operate. We bind the run to a person, a clock, and an observation. Rutagon's own drills are recorded the same way. That habit is not an attestation you can borrow.
Frequently Asked Questions
What belongs in SOC 2 disaster recovery test evidence?
A failover test inside the audit window: operator, start, end, and an observation about the service your procedure names. Restore tests of recovery points are a separate pack. A healthy dashboard from an ordinary day is not a test record.
How do you record an experiment that a stop condition halted?
The stop condition is part of the outcome. We store the identifier and status the service returns, including when an alarm stopped the run, and the reviewer can mark that outcome failed. The record is still filed when the run halts.
What if the only "test" was a real outage?
The outage belongs on the incident record. The failover-test row stays open unless a scheduled test was also run. We do not retitle an incident as the continuity drill to fill the sample.
Who is allowed to be the operator?
One workforce id. A shared mailbox or a team name leaves the row open. The person is the one who started the runbook or the experiment. The GRC ticket id is stored beside that name so the sample can find both.
Where is the pack stored?
In the GRC you already run, on the continuity control you already named. Start and end come from the service or the ticket, not from a screenshot name. A prior window's pack is not offered again once it is outside the window.
Ask us what your GRC platform isn't covering. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.