During the annual disaster recovery test, the team finds that backups of a critical database cannot be restored because the encryption keys were never stored at the recovery site. What should the information security manager do?
Select an answer to reveal the explanation.
Short Explanation
A failed test isn't a failure of testing; it's testing doing its job. You'd much rather find the missing keys on a quiet Tuesday than during a real disaster. Turning off encryption is the trap; you'd fix one problem by creating a bigger one.
Full Explanation
Disaster recovery testing exists to find problems while they can still be fixed cheaply. A restore that fails because the encryption keys are not available at the recovery site is a valuable finding: it shows that the recovery process depends on a resource that was never planned for. The right response is to treat the root cause, which is key management for recovery, by ensuring keys are securely escrowed or replicated where they will be needed, updating the plan and repeating the restoration test to confirm the fix. Reporting the test as passed because the backup jobs completed misstates the result; the objective is recoverability, not backup job success, and management would be misled about recovery capability. Disabling encryption removes the confidentiality protection on the backups and may breach policy or regulatory requirements, trading a solvable availability gap for a confidentiality exposure. Replacing the backup software misdiagnoses the problem, since the software did what it was configured to do and the missing keys would be an issue with any product. Exam caveat: the finding should be reported to management with the remediation plan, as it means recovery was not possible until corrected. Operational check: confirm keys are retrievable at the recovery site by people with recovery roles and that the retest restored the database within its recovery time objective.