The architecture practice did not discover its weak point through an outage. It discovered it during a deliberate exit rehearsal. A completed project was selected, and the team asked a practical question: if this platform had to be left next month, who could obtain every relevant file, remove former consultants, preserve the record of design decisions, and speak to the provider when the export failed? Everyone owned a fragment of the answer. No one owned the whole route. The subscription was active, but the ability to leave was largely assumed.
That distinction matters because the boundary at stake is not a line between a building and a data centre. It runs through staff roles, external accounts, contracts, shared folders, and the ordinary shortcuts that accumulate around delivery deadlines. A drawing can start on an office laptop, be reviewed by a contractor, and sit in a managed service operated through other companies. Each handoff can be legitimate. What matters is whether the practice can trace, explain, and reverse it when a project, supplier, or employment relationship changes.
An exit rehearsal tests stewardship rather than loyalty#
The team began with an uncontroversial folder instead of trying to migrate the whole business. One architect requested an export. A colleague opened the result outside the platform. The office manager found the contract, billing record, and support route. Another colleague listed who still had access, including surveyors and temporary visualisation partners. This division was intentional: an exit should not depend on the one person who knows the administration screen.
The team began with an uncontroversial folder instead of trying to migrate the whole business.
The trial exposed several ordinary gaps. The exported models opened, but some review comments were not included. A consultant who had left months earlier still belonged to a group with broad access. A link to measured-site data was tied to a personal account rather than a named company role. The emergency instructions lived inside the service they were rehearsing how to leave. None of these findings required a dramatic response. They did require the practice to replace assumptions with a clear next owner and date.
<strong>Control is not proved by having a provider; it is proved by being able to recover, explain, and close a relationship with that provider.</strong> This is not an argument for treating cloud services as suspect, nor for building every capability internally. A good supplier can make a small practice safer and more resilient. The point is that convenience does not remove the practice's duty to know where essential material is, who can act on it, and what evidence survives after access ends.
Responsibility becomes useful when it is specific#
“Shared responsibility” often sounds reassuring while concealing a gap. The practice decides which project information is created and who has a business reason to see it. Its administrator grants or removes permissions. The provider operates defined parts of the service. A contractor may receive access to a narrow workspace. When the contractor's engagement finishes, however, information about that change must reach the person who can revoke the account. The risk lives in that transfer, not only in a technical setting.
The team used a small register to make transfers visible. Each important workspace had a content owner, an access administrator, an exception approver, and an escalation contact. Every external account had a purpose and review date. When a new supplier requested access, the question stopped being “can we add this email?” It became: which files, for which task, until which date, and who will confirm removal? This is a modest discipline, but it prevents an informal favour from silently becoming permanent infrastructure.
Contracts belong in the same conversation. Teams should be able to locate the exit window, data-return terms, support channel, retention conditions, and any relevant sub-processors. Reading those provisions does not turn an architect into a lawyer. It gives the organisation practical questions before pressure arrives. If an agreement promises export within a time limit, the rehearsal should test whether the files can actually be opened and used inside that limit. If support requires an account number, that number should not be trapped in one former manager's inbox.
Put the test into ordinary working conditions#
A perfect demonstration proves little. The practice scheduled its rehearsal in a working week, with drawings being revised and site questions arriving. A newer architect, who had not designed the procedure, attempted to follow it. She could not immediately tell which group granted a permission. She found two folders with plausible final versions. She had to ask where the support reference was stored. These were not signs that she had failed. They were observations about a process that expected private knowledge.
The repairs were deliberately narrow. The exit procedure was copied to a separate, accessible location. External accounts had to be linked to an internal owner. Project permissions received expiry dates. The team also created an exception path: if removal would interrupt a genuine delivery, a limited extension could be authorised, recorded, and given a fixed end time. The exception is then visible enough to review, rather than a shortcut that survives because nobody wants to disrupt work.
<strong>A workable boundary does not prohibit every exception; it makes the reason, cost, and end point of an exception reviewable.</strong> Repeated requests for standing access may reveal that a folder structure is wrong, that a supplier needs a proper role, or that the standard process is unrealistic. Treating those signals as learning material produces better controls than blaming the person who tried to finish a task.
Measure the ability to close and respond#
The practice did not create a large dashboard. It chose four observations: external accounts without an internal owner, permissions past their review date, time needed to produce a readable export, and time taken for the escalation chain to respond. These measures do not claim that incidents will disappear. They show whether the organisation can notice a dependency and act before it becomes a crisis.
The first rehearsal report also kept its uncomfortable facts. The export lacked some context. The support response was slower than expected. One account had no clear owner. Recording those facts matters because a green report built on omissions only delays the decision. The practice could now choose whether to adjust its process, ask the provider for a remedy, or prepare a different continuity route. Honest assurance is not a promise that every risk has vanished; it is a clear account of what is covered, what is not, and who will decide next.
This approach also protects people. A consultant should not need to share credentials because the approved invitation takes too long. An administrator should not have to guess whether an account can be removed. A project manager should not learn, during a dispute or outage, that essential files cannot be read outside a single service. By practising the exit early, the team makes these dependencies discussable when colleagues still have time to help one another.
Start with one reversible, observable action#
The office-cloud-provider boundary becomes risky when it is invisible in daily work. It becomes manageable when small decisions leave evidence: a named owner, a dated permission, a tested export, and a real escalation contact. Those controls are not glamorous, but they make continuity less dependent on memory and goodwill.
The next action is concrete. Choose one service holding important but non-critical material, run a controlled export of one folder this week, and record four answers: what came out, what did not, who authorised it, and how long it took. Then assign an owner to the gaps you find. That modest rehearsal turns a blurred boundary into a relationship the practice can understand, challenge, and, if necessary, leave without losing its work or its dignity.
