What we ask before we look at anything
The audit begins with three questions that determine everything about how the rest of the work proceeds.
What does the operation actually do? Not the marketing description; the actual value chain, end to end, with the human beings and the systems that make each step happen. Most operators have a clearer model of what their business sells than of what their business does, and the gap is where the audit work concentrates.
Where does the operation hurt? The pain points the operator can name out loud are the surface signals. They almost always trace back to architectural decisions made years earlier whose consequences only became visible at scale. The audit's job is to find the architectural cause of the surface pain.
What would the operator change if cost were not a constraint? The answer to this question reveals the operator's actual model of what is wrong, often more clearly than direct questions about problems do. Whatever capabilities the operator would prioritise if they could pay for everything is the working list of what they implicitly believe is broken.
The audit produces written answers to all three before any technical examination begins. The technical examination then either supports the operator's working model or contradicts it, and either outcome is informative.
The mapping pass
The first technical pass is a complete mapping of every system the operation runs on. Every recurring software invoice; every internally-hosted system; every database, queue, file store; every integration between these; every credential that controls access to any of them. The output is a one-page diagram that fits on a screen and a longer inventory that documents each entry.
This pass is the most under-done in most operations. Operators routinely cannot list the recurring software invoices their finance function is paying. They cannot describe where their customer data lives. They cannot say which integrations connect which systems. The first iteration of the diagram is usually a surprise to them. The surprise is the audit's first deliverable.
From the diagram and the inventory, several patterns become visible: capabilities that exist in two or three places without anyone realising; data flows that depend on integrations no one is monitoring; credentials that are shared between humans and machines; subscriptions that are paid for capabilities the operator no longer uses. The mapping pass often reduces the cost surface of the operation by ten to twenty percent before anyone has architecturally redesigned anything.
The dependency pass
The second technical pass examines the dependencies. For each system, we ask: what would it cost the operation if this disappeared in ninety days? The cost is not just the replacement project; it is the operational degradation during the transition, the data extraction risk, the staff retraining cost, the integration rebuild, the political capital spent renegotiating with counterparties.
The answers come back in tiers. Some systems are trivial — replaceable with a few hours of work, no operational impact. Some are moderate — replaceable with a few weeks of work and a recoverable degradation. Some are heavy — replaceable with months of work, meaningful operational pain during the transition. And some are existential — losing them in ninety days would not just be expensive, it would threaten the operation's ability to deliver to its customers at all.
The existential dependencies are the audit's most consequential output. Every existential dependency on a third-party rental is, by definition, a strategic vulnerability the operation is currently absorbing. The audit names these clearly and ranks them by the credible probability of disruption over the next five years. Most operators are quietly horrified by what shows up here.
The architectural pattern pass
The third pass looks at the patterns in how the operation has been built, not just what it has been built with. Are systems integrated point-to-point or through a central orchestration layer? Are credentials managed centrally or scattered? Is observability ambient or non-existent? Is GitOps discipline in place or are servers configured by hand? Is identity a coherent concept or is each system its own islands?
The pattern pass is where the architectural maturity of the operation becomes visible. A small operation can have excellent architectural patterns; a large operation can be a chaos of point-to-point integrations and tribal knowledge. The size of the operation does not determine the maturity. The deliberateness with which it was built does.
The output of this pass is a maturity scorecard across a small number of architectural dimensions, with explicit notes on where the operation is strong, where it is weak, and what the highest-leverage improvements would be. The scorecard is not abstract. It is tied directly to the dependencies, the costs, and the pain points identified in the earlier passes.
The deliverable
The audit deliverable is a written document, typically twenty to forty pages, with the following structure.
- Executive summary that fits on one page and is readable by a non-technical owner.
- The current state — diagram, inventory, dependency map, architectural maturity assessment.
- The risk register — every existential dependency named, ranked by probability and impact.
- The recommended migrations — prioritised, with rough cost and timeline estimates for each.
- Explicit recommendations on what to leave alone — the parts of the stack that are correctly built and should not be touched.
- A small set of immediate actions — usually three to five — that produce visible improvement within a quarter regardless of whether the larger migration is undertaken.
The deliverable is intentionally written so that a competent operator can act on it without further engagement with us. We are not building a dependency on us; we are providing a working artifact that the operator owns. If the right decision after reading the audit is to act on it themselves or to engage a different operator, that is the right decision and we say so explicitly.
The takeaway
The stack audit is a discipline, not a sales tool. The methodology is structured because operators benefit from structure, and the deliverable is unsentimental because the alternative is consulting theatre. Operators who are evaluating whether to bring critical infrastructure back in-house, or who suspect their stack has accumulated drift they cannot quite see clearly, are the readers for whom this kind of audit produces value.
The most common outcome of an audit, in our experience, is not a large rebuild. It is a small set of well-prioritised changes, a clearer map of the dependencies the operation is willing to accept, and a written record the operator can return to when the next strategic decision needs context. That is, on the right horizon, the most useful thing a single engagement can produce.
Working on this?
For operators evaluating sovereign-infrastructure architecture for a business of meaningful scale, we run a quarterly cohort of stack-design engagements.
Get in touch