Moving core infrastructure to the cloud is often treated as a security upgrade in itself. It is not. It moves the trust boundary; it does not remove the need to prove where that boundary now sits, and for a public-interest body, that proof has to satisfy an audience well beyond its own IT team.
The client is a national securities regulator partway through migrating core oversight systems to the cloud. Its position is unusual: it has to meet a higher bar than the market participants it supervises, and its own credibility depends on being able to demonstrate that the bar was met, not simply assert it.
The architecture diagrams described an intended state that had drifted from what was actually running. Trust boundaries existed on paper in places where, in practice, identity and data moved across them more freely than the diagram implied. Before anything else, the real environment had to be mapped as it existed, not as it was designed.
We built a current-state architecture and trust-boundary map, then ranked the resulting findings by business consequence rather than technical severity: a finding that would embarrass the regulator in front of its own overseers was treated differently from one that was merely untidy. That prioritisation was, on its own, as valuable to the client as any individual finding.
Alongside the findings, we produced a target-state reference architecture and a governance model that named an owner for each control area, because the recurring problem in organisations of this kind is rarely a lack of good intentions. It is that no single person is accountable when the architecture and the diagram disagree.
The outcome that mattered most here was not a single metric. It was that the regulator's own leadership could, for the first time, point to a defensible account of its cloud environment when its overseers asked. Closing the remaining gaps against the target-state architecture is ongoing work, sequenced by the roadmap we left behind.
The pattern generalises past this one client: any organisation whose cloud migration has outrun its own architecture documentation is carrying a gap it cannot currently prove it does not have. Finding that gap before someone else does is the entire point of doing this work early.