Reuse the workspace without inheriting the authority

## Find the decision the template has already made

The customer-workspace pattern looked like an administrative improvement. It offered a consistent structure, familiar screens and less repeated setup when a new relationship began. I approved it for those reasons. What I failed to require was a clear account of the authority carried by its inherited groups and permissions. When the pattern was reused, a business decision about who could see particular information travelled with a technical convenience. The next user received that decision without necessarily recognising that it had been made on their behalf.

In our 2023 review at Vornqemi Thermal Services, 240 documents were examined and forty-eight had been available outside the intended customer group. The finding concerned a defined collaboration service. It did not establish a problem in plant-control systems or justify an assertion about every information service the company operated. I wanted the scope stated carefully while taking the actual finding seriously. A limited incident is still consequential within its boundary, and a broad description can make the response less useful by confusing the people, evidence and authority involved.

Reuse is not inherently careless. Repeating a sound structure can reduce errors and free colleagues to focus on the work that actually differs. The difficulty is deciding which elements are safe to repeat without further judgement. Folder names and an agreed document sequence may be suitable candidates. Customer audiences, confidential material and rights associated with a particular relationship may need fresh examination. The management question is not whether a pattern can be copied. It is whether the copied pattern contains decisions that belong to the new setting rather than the old one.

The original approval was mine, so I could not reasonably treat the problem as a failure confined to the person who created the next workspace. I had encouraged repeatability without specifying the review needed around its authority. A stronger definition of completion would have required the responsible business owner to explain the intended audience and suitable technical evidence that the arrangement behaved accordingly. That would not have made every future error impossible. It would have made the permission decision visible and assigned, instead of leaving it implicit in a familiar configuration.

## Distinguish a corrected setting from a completed response

Once the problem was identified, we needed to correct inappropriate availability promptly and preserve the evidence required to understand it. Those responsibilities were related but not identical. Changing a permission could address the current configuration while leaving questions about earlier access and consequences unresolved. I resisted the proposal to announce completion as soon as the groups were corrected. Qualified security, legal and customer-relationship owners needed to assess what the available evidence supported and which actions or communications were appropriate to the actual circumstances.

Logs showed access to fourteen of the forty-eight documents. For thirty-four, no access event was observed in the evidence available to the review. That distinction had to survive into the management account. An absence of a recorded event was not a universal finding that nobody had accessed the material. Equally, inappropriate availability did not allow us to invent a specific consequence for every document. The report needed to preserve what was known, what was not established and who remained responsible for the next assessment. A neat binary label would have hidden more than it explained.

We funded ₹58 lakh for response, review and changes. The expense belonged in the account of the decision; it was not presented as money recovered or a quantified prevention benefit. My team supplied technical work and evidence while the relevant specialists assessed obligations and consequences. Customer material was not reproduced in the public explanation. The purpose of a leadership case is to show the judgement and accountability involved, not to make private information perform as proof of authenticity. A candid account can remain specific about its decision while protecting the records that should not be published.

Technical director Yusuf Dorzemi helped keep the operating boundary clear. The collaboration service did not give the CIO authority over thermal processes, engineering acceptance or customer installations. An incident in one information arrangement should not create an improvised mandate to intervene in another. The response needed cooperation among the responsible owners, with each able to explain the part they understood. I could coordinate and fund that work, accept responsibility for the earlier approval and ensure unresolved matters stayed visible. I could not replace every professional conclusion with my own declaration that the system had been repaired.

## Make reuse accountable without abandoning it

The revised workspace process required an explicit audience decision for the new customer setting. Suitable test material and the responsible owners were involved in examining the access behaviour. The intention was to preserve useful common structure while making the consequential permission decision harder to overlook. I would be cautious about presenting that as a universal configuration recipe. Different services and business relationships have different control requirements. What should transfer is the leadership question about inherited authority, together with a demand for evidence appropriate to the service being approved.

There was a real cost in convenience. Colleagues could no longer treat a familiar pattern as a complete answer to the setup question. Someone had to explain the intended audience and consider whether the relationship differed in a material way. The process needed to remain proportionate so that necessary review did not become meaningless paperwork. I wanted the business owner and technology team to share a clear question, rather than create a long form whose completion would later be mistaken for assurance. The value lay in the decision made and the behaviour examined, not in the presence of another administrative artefact.

For a board, the case raises questions about how management recognises the obligations hidden in standardisation. Which decisions does a common pattern make? Who can approve a departure? What evidence distinguishes a setting that has been changed from an incident whose consequences have been assessed? How are incomplete findings represented in the board account? Directors should be able to examine those questions without becoming system administrators or deciding incident communications without the appropriate advice. Useful oversight makes executive accountability clearer rather than dispersing it across people who do not operate the service.

The lesson also applies to the way leaders discuss scale. A pattern that works in one relationship may help the company grow, but the ability to reproduce it does not prove that every inherited assumption fits every customer. Growth increases the value of common arrangements and the consequences of an unchecked assumption. I would ask the sponsor of a repeatable process to name which parts are standard and which require a fresh decision. That conversation should occur before the next customer is present, when changing the pattern is still a design choice rather than a response to a discovered exposure.

I remain in favour of reuse. What changed is my view of what should travel with it. A useful pattern should carry its explanation and its limits, including the decisions that the next owner must make again. In this case, correcting permissions was necessary, but the more lasting management correction was to recognise that convenience had concealed authority. I want the next approval to ask who may rely on the arrangement and why, before a copied structure makes that answer look settled merely because it has been used before.