IT promises same-day restore for a permit system that has never been restored in a drill, and leadership wants that promise written as the RTO. How should BIA-informed recovery needs be set?
Select an answer to reveal the explanation.
Short Explanation
Promising a same-day pizza delivery from a kitchen that has never cooked is just hope on a whiteboard. BIA says how long the business can actually tolerate being down. Ground RTOs in impact needs and tested capability—not cheerleading.
Full Explanation
Recovery time objectives for civic systems should be grounded in validated business impact—how long a function can be unavailable before unacceptable harm to permits, revenue, safety, or public trust—not solely in untested IT restore promises. Same-day restore claims for a permit system that has never been restored in a drill are aspirations until proven. BIA-informed recovery needs set credible RTOs and drive testing so declared objectives match demonstrated capability.
Accepting an untested same-day RTO because written promises automatically equal capability confuses documentation with evidence. Removing RTOs from planning documents so untested systems cannot create false confidence avoids the symptom while abandoning a core planning control. Lengthening every RTO to thirty days so no promise needs testing abandons impact-based prioritization and may leave citizen services intolerably down.
Exam caveat: distinguish business-tolerable downtime (BIA) from technical restore claims. CRMC items frequently pair aggressive IT promises with missing restore tests.
Operational check: document maximum tolerable downtime from BIA workshops for the permit function; set the RTO no tighter than impact needs require and no looser than leadership accepts; schedule a restore drill that proves or revises the objective before publishing it as municipal capability.