A technology project can finish while leaving behind work that must recur for the service to remain usable. The original team may have configured the connection correctly, documented its details and demonstrated that it works. None of that establishes who will act when a future condition changes. An expiry date can sit in a technical record without being attached to an accountable person who has the authority, capacity and service context needed to handle it before interruption occurs.
In 2023 certificate expiry interrupted two of our twelve partner interfaces for ninety-four minutes. The case concerns those connections. It does not establish that every customer was affected or that the interruption involved a breach. We needed to understand the incident and restore the appropriate service through authorised technical work. We also needed to examine the continuing ownership behind similar dependencies, rather than assume the only useful response was to correct the particular date that had just caused a problem.
A review covered thirty-six service certificates. Twenty-seven had an accountable owner and nine did not. The inventory was not empty; dates and technical details existed. The missing element was accepted responsibility for the recurring work. That finding challenged a familiar assurance: the material was documented, so somebody would surely act on it. Documentation can make an obligation discoverable without making anyone responsible for carrying it out. The difference becomes visible when the obligation arrives during other planned work.
The project had ended but the obligation had not
Implementation teams are often organised around a defined release. They build, test and move on. A service dependency can require attention long after that release, sometimes involving partners and approvals outside the original team. If the continuing work is not accepted explicitly, responsibility remains attached to whoever remembers the arrangement best. That may work for a time, but it is a fragile basis for a service on which operating colleagues rely. Memory is not the same as an owned obligation.
We allocated ₹48 lakh to the inventory, ownership and renewal-exercise response. A reporting release moved by two weeks to provide capacity. I kept the delay visible because the work could not honestly be described as a free administrative improvement. People who had expected the reporting change needed an explanation of the revised priority. The decision meant accepting a known delay elsewhere to establish a more credible account of a dependency that had already interrupted service.
Technology and service colleagues assigned accountable owners across all thirty-six certificates and established renewal testing through the authorised workflow. The public account does not include production credentials, sensitive connection details or operating commands. Those are not needed to explain the leadership judgement. The important point is that the inventory became connected to people who understood both the technical work and its consequence for the service, with a practical process for testing the change rather than treating an updated date as sufficient evidence.
Connect technical ownership with service consequence
The technical owner needs to understand how a renewal is performed safely and what other components or partners depend on it. The service owner needs to understand when interruption would matter, who should be informed and which work requires coordination. Those responsibilities are related but not identical. Assigning the entire issue to one group without the other can leave a technically correct action poorly timed or an operating request unsupported by the knowledge needed to carry it out properly.
This is not an argument that every dependency needs a large committee. It is an argument for a clear connection between the people who can change the system and those accountable for the work it supports. The appropriate arrangement depends on the service. The CIO should be able to ask who has accepted the obligation and what evidence shows the response works, without requiring a new layer of approval for every routine action. Clarity of responsibility can simplify work when it replaces uncertainty about who must be involved.
The incident also required careful reporting. Ninety-four minutes across two interfaces is a defined service interruption, not a universal measure of customer impact. We did not infer claim outcomes, financial loss or a security incident from that duration alone. A stronger impact claim would require additional evidence from the relevant owners. Keeping the account bounded allowed the review to address the ownership failure without using an invented consequence to justify work that already had a clear operating purpose.
A named owner still needs time and evidence
Assigning names does not prove that all later renewals will succeed. The owners need the capacity and authority to do the work, and the process needs to remain useful as services change. A new partner, a changed connection or a departure can alter the responsibility account. The review therefore did not end with a promise that interruption had become impossible. It established a better basis for continuing work, whose performance still needed to be observed rather than assumed from the existence of a list.
Testing also matters because a renewal is not complete simply when a technical record shows a new date. The service must operate through the changed arrangement under the appropriate conditions. That verification belongs with authorised teams and should reflect the real dependency. The exact method is a technical matter, but the leadership question is straightforward: what demonstrates that the service still works after the action? A completed administrative task should not inherit the meaning of a tested connection without the corresponding evidence.
For a board, this case illustrates how a seemingly small technical obligation can expose a larger management question. Does the organisation know which responsibilities continue after projects close, and are they resourced within the operating model? Directors need not manage certificate inventories. They can ask how management establishes continuing ownership and how it learns from a failure without claiming that one review resolves every related risk. The answer should connect people, recurring work and service evidence, rather than offer reassurance based solely on documentation.
I now look at an implemented interface as the start of a continuing service relationship. The project result matters, but so do the obligations it leaves behind. The two interrupted connections and nine unowned certificates made that distinction concrete. We accepted expense and a release delay to give the work a more credible home, while retaining uncertainty about future performance. An expiry date can tell the organisation when something needs attention. Only an accountable, supported owner can make the necessary work part of the service rather than a problem rediscovered when the date has already passed.