System Backup Checklist

Catalog the policy admin platform (Guidewire PolicyCenter, Duck Creek, or Insurity), the AMS (Applied Epic, AMS360, EZLynx), claims systems (ClaimCenter, Snapsheet), and document repositories (ImageRight). Anything holding NPI under GLBA or PHI under HIPAA is in scope. Printer spools, TPA portal exports, and email archives are easy to miss under NYDFS Part 500 §500.11.

Health, dental, vision, and stop-loss carriers fall under the HIPAA Security Rule in addition to GLBA. P&C-only carriers usually do not, but check whether the carrier writes any group health products before answering No.

Capture encryption-in-transit, encryption-at-rest, access logging, and the 6-year retention floor for PHI backups. The HIPAA Security Rule contingency-plan standard (§164.308(a)(7)) requires a documented data backup plan, disaster recovery plan, and emergency-mode operations procedure — all three, not just the backup plan.

Most P&C policy and claim files require 5–7 years of retention; workers' compensation often runs 10+ years given lifetime medical exposure. Pull each state's records-retention rule and the carrier's WC manual before destroying anything — premature destruction creates discoverable spoliation risk.

Confirm replication to the secondary region or offsite tape vault completed cleanly since the last cycle. A backup that exists only on the primary array is not a backup — and a single-region failure during a regional cloud outage will surface as a market-conduct finding.

Schedule the full during a low-traffic window — typically Saturday night for the AMS and Sunday morning for policy admin to avoid colliding with rating-engine batches and overnight commission runs.

Incrementals capture diffs since the last full. Verify the incremental chain is intact end-to-end; a broken link in the middle means a restore will fail at exactly the wrong moment, typically discovered only during the next test cycle.

NYDFS Part 500 §500.15 requires encryption of NPI in transit and at rest unless infeasible and approved by the CISO in writing. AES-256 is the standard floor; verify the encryption status on the actual backup media, not just the policy setting in the console.

Pick a random policy bound this quarter and restore the dec page, application, and underwriting file. A restore that succeeds at the file-system level but produces a corrupted policy record fails the test — verify the record opens cleanly in PolicyCenter or the AMS.

Restore a closed claim with adjuster notes, recorded statements, and photo attachments. Claims data with binary attachments is the most common restore-failure scenario — the metadata restores cleanly but the BLOB references break.

Compare the actual restore window against the carrier's documented RTO. If the RTO is 4 hours and the test took 9, that's a finding regardless of whether the restore succeeded — the BCP is out of date.

Restore success means the data is complete, accurate, and accessible — not that the job finished without errors. A 'completed' restore producing a corrupted policy file or unreadable PDF attachment is a No.

Reflect any change in scope, schedule, encryption configuration, or retention in the Written Information Security Program. Auditors compare the WISP to the actual workflow — a runbook that describes a tape rotation the team stopped using two years ago is a finding.

Pull the most recent SOC 2 Type II report and confirm coverage of the Availability and Confidentiality trust criteria. Part 500 §500.11 vendor oversight requires evidence on file — a returned questionnaire alone does not satisfy the standard.

Tie out completed jobs against the expected weekly schedule. Any gap — missed full, broken incremental chain, skipped offsite copy — becomes an input to the biennial risk assessment under Part 500 §500.09.