I have sat in a lot of rooms where a technology audit was being "presented," and I have noticed a particular silence that settles over those rooms about twelve slides in — not the silence of concentration, but the silence of people who have quietly stopped following and are now waiting for the conclusion. The slide deck has become the default deliverable of the consulting world, and I think it is a genuinely bad default, one that flatters the presenter and obscures the work, and nowhere is that more costly than in a technology audit, where the findings are dense, the dependencies are non-obvious, and the stakes of misunderstanding tend to compound over the following eighteen months. I want to make the case, as plainly as I can, for the written report — not as a nostalgic preference, but as a structural argument about what audit findings actually require in order to be understood and acted upon. This is not a polemic against slides as a medium; it is a specific argument about the mismatch between what a technology audit produces and what a slide deck can hold.
What a slide deck does to a finding ¶
The atomic unit of a slide deck is the bullet point, and the bullet point is, by design, a compression device. It removes connective tissue. It strips causality. It replaces "the authentication service is failing intermittently because the session token TTL is misconfigured relative to the load balancer's idle timeout, and this only surfaces under concurrent user loads above roughly four hundred" with something like "Authentication issues — load balancer config." These are not equivalent statements. The first one tells a CTO exactly where to look and why. The second one tells a room of people that something is wrong somewhere, and invites three days of confused back-and-forth before anyone actually opens the right configuration file. I have watched this happen — specifically, I watched it happen at a mid-size logistics company in late 2022, where a perfectly competent audit team delivered a beautiful deck, and the infrastructure lead spent six weeks investigating the wrong service because the slide had not preserved the conditional logic of the original finding. The deck looked professional. The follow-through was a mess.
The performance problem — how decks shift attention to the presenter ¶
There is something else that happens in the slide presentation that I find worth naming honestly: the room's attention moves to the person speaking rather than to the content. This is partly by design — slides are a presentation medium, not a reading medium — but in the context of an audit, it creates a subtle and consequential distortion. The client is evaluating the consultant's confidence, their fluency, their ability to handle questions smoothly, at exactly the moment when they should be evaluating the findings themselves. I have seen audit teams present genuinely mediocre work with great confidence, and I have seen meticulous, carefully reasoned work delivered awkwardly and dismissed on that basis. The written report removes this variable almost entirely. The reader is alone with the argument. The prose either holds up or it does not. The reasoning is either traceable or it is not. There is no charisma to compensate for a weak causal chain, and no nervous energy to undermine a strong one. This is, I would argue, exactly the epistemic condition you want when someone is about to make decisions about your technology infrastructure.
What a well-structured written audit report should actually contain ¶
The written audit report I would want to receive — and the kind I try to produce — has a specific shape. It opens with an executive summary that is genuinely a summary: three to five paragraphs that name the most critical findings, their severity, and the recommended order of remediation, written for someone who will read nothing else. Then comes a methodology section, not as boilerplate, but as a specific account of what was examined, what access was granted, what was out of scope and why — because a finding's weight depends entirely on the conditions under which it was discovered. Then the findings themselves, each one structured as a short essay: what was observed, what the evidence was, what the likely cause is, what the risk profile looks like across different scenarios, and what a remediation path might involve. Not a bullet. A paragraph. Sometimes several paragraphs. And finally an appendix that contains the raw data, the configuration excerpts, the log samples — the primary sources that allow a technically capable reader to verify every claim without taking anything on faith.
On the question of length, and why 'too long' is often the wrong complaint ¶
The most common objection to the written report is that nobody will read it. I want to push back on this, because I think it conflates two different problems. If your written report is long and nobody reads it, the problem may genuinely be length — but it is more likely to be structure. A forty-page report with clear section headings, a precise executive summary, and findings that are consistently formatted is navigable. A reader can spend eight minutes with the executive summary, then turn directly to the two findings that are most relevant to their role, read those in full, and have extracted enormous value. A forty-eight-slide deck cannot be navigated in this way — it is sequential, it requires the presentation to give it context, and its shelf life is essentially the duration of the room. I have returned to written audit reports eighteen months after first reading them and found the reasoning as useful as it was the first time. I have never once returned to a slide deck and found the same.
The version control argument — why documents age better than decks ¶
Here is a practical consideration that I do not hear discussed often enough: technology environments change, and audit findings need to be revisited. When remediation work begins — when the infrastructure team starts working through the findings over the following quarter — they need to be able to return to the source document, understand the original context, and determine whether a proposed fix actually addresses the root cause as it was described. A written report, especially one kept in version-controlled storage, supports this workflow naturally. You can annotate it, track which findings have been closed, add notes about what the remediation actually involved versus what was recommended. A slide deck is essentially static. It was designed for a moment, and it does not evolve with the work. Some of the best follow-up processes I have seen treat the written audit report almost like a living document for the first six months — not revising the original findings, but maintaining a companion document that maps each finding to its current status, its assigned owner, and the date it was closed or escalated.
A word about what this asks of the auditor ¶
I should be honest about something: writing a good audit report is significantly harder than building a good slide deck. The slide deck allows a kind of modularity — you can add a finding as a bullet without having to work out exactly how it relates to the finding three slides earlier. The written report forces you to work that relationship out, because prose is a relational medium. When you write "this finding compounds the risk identified in section 3.2," you have to actually understand how it compounds it, and be able to say so coherently. This is uncomfortable work, and it is the right kind of discomfort. The act of writing the report is, in my experience, one of the most reliable ways to discover that a finding you thought you understood is actually less clear than you believed. The slide that says "database indexing — performance risk" may have felt complete when you created it. The paragraph that tries to explain exactly which queries are affected, under what load conditions, and what the performance degradation curve looks like will, reliably, reveal the gaps in your own analysis. The written report does not just communicate the audit. It completes it.
If you are a client receiving a deck, here is what to ask for ¶
If you are on the receiving end of a technology audit and the deliverable you have been offered is a slide deck, I would encourage you to ask, plainly, for a written report — or at minimum, for written findings behind each slide. Most consultants will accommodate this if asked directly. What you are looking for, specifically, is prose that can stand on its own without the presenter in the room, findings that name their evidence explicitly, a clear methodology section, and a recommendations section that is honest about trade-offs rather than presenting remediation as a uniform list of equally urgent items. It is also worth asking how the report will be stored and whether it can be shared with the technical team leads who will actually implement the remediation — because a finding that only the CTO has seen, in a deck format, on a laptop they no longer use, is a finding that has already been half-forgotten.
The slide deck is not a document. It is a script for a performance, and once the performance is over, most of what made it meaningful disappears with the presenter. Technology audits are too consequential — and the findings they surface too interdependent — to be entrusted to a medium designed for rooms and forgotten after the meeting ends. Write it down, all of it, in full sentences, with the causality intact. That is the deliverable that earns its keep.