Testing access to critical support records during disruption

Test whether authorised agents can retrieve the few records needed for urgent work when the helpdesk is unavailable. A completed export is only a starting point. The exercise succeeds when an agent can identify the right case, read the necessary history and find its next action through an approved access route.

Choose records by the work they support

List case types that cannot reasonably wait for the platform to return. For each, identify the case reference, customer contact route, latest public exchange, owner, pending action, promised follow-up and any file needed for the next decision. Keep the fallback set narrow and protect it under the organisation’s access and retention rules.

State how current the information must be. A nightly copy may show older history but miss a commitment made this morning. Record its creation time and time zone. When a current fact is essential, specify who may check the authoritative source separately.

Critical record fields to protect for urgent work

Check what the extraction contains

Export methods differ. Zendesk supports account data exports to JSON, CSV or XML, and its export guidance directs administrators to check which data each file type can export. Confirm that the selected format contains the case details needed for the exercise.

A row count cannot establish that agents have the conversation they need. Zendesk’s incremental export API returns items that have changed or been created since the last request and has an include parameter for side-loading a resource. Check the relevant endpoint documentation and test whether the output contains the content needed; arrange an authorised extraction in advance.

For any platform, compare sample output with source cases while the service is available. Include a long conversation, an internal note, an attachment and a recently changed case. Check author, time, visibility and file access. An internal note must remain restricted in the fallback view.

Extraction contents to verify before relying on fallback

Run a retrieval exercise

Use de-identified records or an authorised test environment. Give an agent the fallback instructions and a case reference. Ask them to find the latest customer question, the action promised and the owner who can continue the work.

Include an ambiguous match and a record newer than the copy. When the evidence is insufficient, the appropriate result may be to pause an account-specific answer and arrange verification.

Record each result as found, incomplete, inaccessible or too old, with a reason and correction owner. Check access for the roles and locations expected to use the fallback. A storage administrator’s retrieval does not establish that a support agent can use the records appropriately.

Run a retrieval exercise

Reconcile after disruption

AWS backup guidance recommends periodic recovery to verify backup integrity and processes. Apply that principle to the support fallback by retrieving and reading a sample.

During a disruption, record decisions and customer promises made from fallback material, marking facts that may be stale. When the helpdesk returns, compare those actions with the live case, add the relevant updates through the approved workflow and resolve duplicates.

Reconcile fallback actions with live cases