Journal

A contract is signed, the vendor begins work, and the implementation moves forward. Somewhere in the agreement are commitments about recovery, accessibility, incident notification, security reviews, data handling, and service availability. During procurement, people discussed those provisions carefully. After execution, the contract was filed and attention shifted to delivery.

The security team wants an application patched immediately. Operations wants to wait until after a critical business cycle. The vendor says the patch requires an upgrade that has not been tested with the agency’s configuration. Each position has a reasonable basis. Each also carries consequences.

Ask an IT department how it approaches governance, and the conversation may quickly turn to frameworks. Which one should we adopt? How mature are we? Which controls have we implemented? How do we measure our progress? Those are useful questions. But there is a more immediate question underneath them: What is this organization actually obligated to do?

The recovery test ticket is closed. The team ran the exercise, attached the results, and marked the work complete. Three months later, someone asks a different question: “Have we satisfied our recovery obligations for this application?”