Your Ticket Queue Isn’t an Obligations Register

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?”

The ticket tells you that an exercise happened. It may take considerably more digging to establish whether it covered the right systems, tested the required recovery targets, addressed the current review period, and produced results someone was authorized to accept.

That gap is easy to overlook when the dashboard is green.

Ticket queues are useful because they make work manageable. They give people assignments, priorities, deadlines, and a place to record progress. An obligations register serves a different purpose: it establishes what the organization is responsible for, why that responsibility exists, where it applies, and how the organization knows whether it has been met.

The two should connect. Treating them as interchangeable creates problems that better ticket hygiene alone cannot solve.

An obligation can exist long before anyone creates a ticket. A contract may require an annual recovery exercise. An internal standard may establish recovery targets. A policy may require someone to review and approve the results. Those responsibilities continue to exist whether the queue contains three related tickets, one recurring task, or nothing at all.

A ticket usually begins with an action: conduct the exercise, review the report, resolve the finding.

An obligation begins with a responsibility: this application must demonstrate that it can recover within an established period, under defined conditions, at a specified frequency.

That distinction changes what you need to record.

“Run the recovery test” may be a perfectly reasonable assignment. But it leaves several questions unanswered. Which application and dependencies are included? What establishes the requirement? What counts as success? Who owns the obligation? Who can decide that the evidence is sufficient? When does that conclusion need to be revisited?

Those details can be included in a ticket. The challenge is keeping them coherent across repeated exercises, changing owners, revised requirements, and multiple pieces of work.

Consider an exercise that finishes on schedule but misses its recovery target.

The team completed the assigned work. Closing the exercise ticket may accurately reflect that fact. The exercise also produced evidence that the obligation has not been satisfied.

A remediation ticket can capture the next action. Closing that ticket establishes that someone completed a corrective task. Depending on the circumstances, another test may still be needed before anyone can conclude that the application meets its recovery requirement.

There are several separate facts here: the exercise occurred, the results showed a deficiency, corrective work was completed, and the outcome may or may not have been validated.

A single “closed” status cannot express all of them clearly.

The same issue appears in accessibility reviews, vendor assessments, contract commitments, and other governance work. Completing a review does not guarantee a satisfactory result. Uploading a document does not establish that it is relevant, current, or sufficient. Accepting a risk may authorize continued operation without demonstrating that the underlying requirement has been met.

These distinctions matter because people make decisions based on the status they see.

A dashboard that reports every related task as complete can create confidence that the underlying records do not support. Meanwhile, an overdue task may concern an administrative update rather than a lapse in the obligation itself. Work status and obligation status inform each other, but they answer different questions.

Time adds another complication.

Last year’s recovery exercise may support last year’s conclusion. It does not automatically establish this year’s position. A material application change may also affect whether earlier evidence remains useful.

The organization needs to preserve the history while making the current position understandable: what period was evaluated, what evidence supported the decision, what gaps remained, and when another evaluation is due.

Ownership needs similar continuity. The person assigned to perform a test may be different from the person accountable for the application’s recovery obligation. When an assignee changes jobs, that obligation still needs an owner. When a project ends, ongoing responsibilities still need somewhere to live.

None of this requires abandoning the tools people already use to do their work.

A practical arrangement lets the obligations register hold the continuing governance context and lets the ticketing system coordinate execution. The register identifies the requirement, its source, its applicability, the accountable owner, and the basis for evaluating satisfaction. Tickets organize the activities needed to produce evidence or resolve gaps.

Links between them let someone move from a governance question to the supporting work without reconstructing the relationship from search results and institutional memory.

That separation is central to the thinking behind IT GO: an organization should be able to explain its obligations and its current position, while allowing the people doing the work to use appropriate operational tools.

A useful test is to choose one important application and ask:

“What are we obligated to do, why, who owns it, and what supports our current conclusion?”

If answering requires reading a collection of closed tickets and asking the person who remembers what happened, the queue is carrying more responsibility than it can reliably express.

The work may be complete. The organization still needs a clear basis for saying the obligation is satisfied.