The systems audit

Read-only is a technical constraint, not a courtesy. Credentials are requested at the lowest level that permits the work, nothing is modified, and access is revoked at the end of the engagement. An audit that alters what it measures has compromised its own findings, and the temptation to fix something small along the way is exactly how that happens.

The inventory comes first, and it is more work than it sounds. Every running service, every scheduled job, every third-party account, every domain, every certificate, every credential — and the item that is missing more often than any other, which is who is able to change each of them. Most organizations have never had this written down in one place.

Getting access is part of the audit, not a precondition for it. How long it takes to obtain read access to everything, who has to be asked, and how many of those requests reach one particular person are all observations about the organization — and where nobody can grant access to a system because nobody is certain who controls it, that difficulty is itself among the more serious findings in the report.

People are interviewed, and what they say is recorded as testimony instead of as fact. "The nightly job has never failed" is evidence about what is believed, which is worth knowing and is not the same as evidence about the job. Where a claim can be checked it is checked, and where it cannot, the report says who said it and that it was not verified. Most of the interesting gaps in an audit sit exactly where confident belief and observable behavior have quietly diverged.

What is load-bearing is identified separately from what is prominent, because the two frequently differ. The system everybody talks about in meetings is often not the one that stops the business when it fails. That is usually something small, undocumented, written years ago for a narrow purpose, and now quietly sitting in the path of something important.

Cost to run is established from bills instead of from memory. Recurring spend spread across a dozen vendors, some of it on somebody's personal card, some renewing annually on a date nobody tracks, is the normal state of affairs. Assembling that total is regularly the most immediately useful page in the report, and it is also the one that takes the least skill to produce — it simply requires that somebody do it.

Single points of failure are named individually rather than grouped. A service with one deployment path, no staging environment, and a credential held by one person is three findings and not one, because they are fixed separately, cost different amounts, and carry different urgency.

What will break next is a prediction, and it is labeled as one. Framework versions past their support window, certificates with an expiry date, dependencies carrying published advisories, a domain due for renewal, a vendor sunsetting an API — each with its date attached, so the reader can sort the list by calendar instead of by adjective.

Knowledge that exists only in someone's head is recorded as a risk with a name. The finding names the process, not the person, because the remedy is to write the process down instead of to hire a second person to remember it, and a finding phrased as a personnel dependency invites the wrong fix.

Findings are ordered by consequence — not by the order they were discovered, and emphatically not by how interesting they were to find. The most interesting finding in an audit is very often the least important one, and a report ordered by the auditor's enthusiasm spends the reader's attention on the wrong page.

Each finding carries an estimate of what it costs to leave alone, which is the number that makes prioritization possible at all. A list of problems with no cost attached is a list that gets read once, produces agreement that something should be done, and is never opened again.

The report is written so that a reader who disagrees with a recommendation can still use the evidence. Observation and interpretation are separated structurally instead of by tone, so that rejecting a conclusion does not require rejecting the facts underneath it. A document that fuses the two has to be accepted or discarded whole, and most people discard.

It is written for two readers at once. An operator needs the detail; an owner needs the consequence and the cost. That is a summary stating the three things that actually matter, supported by a body that carries the specifics — not an executive summary that is the same prose at half the length.

What the audit did NOT examine is stated explicitly. Every engagement has a scope and a duration, and a report silent about its own boundaries invites the reader to assume it covered everything. The areas left unexamined are listed with the reason, which is usually time and occasionally lack of access.

The engagement is scoped, time-boxed, and priced before it begins, and the report is delivered on those terms regardless of whether its conclusions point toward further work. Nothing about the fee depends on what the findings say.

The inventory is delivered as something the business keeps instead of as an appendix. A report is read once and ages; a maintained list of every service, account, credential and owner is the artifact that keeps paying, and handing it over in a form somebody can actually update is worth more than any single finding in the document it arrived with.

The most common reaction to a finished audit is not surprise at any individual finding. It is surprise at the total. Almost every item in it was known by somebody; almost none of it was known by one person, and essentially none of it was written down. Assembling it into a single document that one person can hold in their head is most of the value, and it is the part that no amount of internal familiarity substitutes for.