What's actually in a StackRefit audit

The sample audit report is a real deliverable. It is anonymized, but the structure, length, and depth match what every audit engagement produces. It is also dense — twelve sections, a stack inventory, a 23-row risk register, a tested restore transcript, a 30/60/90-day roadmap.

This is the reading guide. For each section, what it shows, why it is in the audit, and what to look for when you read your own.

01 — Executive summary

The first page of the audit. Severity counts (critical / high / medium / low), the top three actions for the next fourteen days, and a one-paragraph framing of the system’s overall posture.

The reason it is one page is that it has to be readable by a non-technical reader — a founder, an account lead, a board member — without losing the load-bearing facts. If the executive summary cannot be quoted directly into a stakeholder email, it is doing its job badly.

What to look for in your own: the top three actions should be specific (e.g. “test a restore on the most recent backup”), not abstract (“improve operational maturity”). → Sample: executive summary

02 — Engagement context

Scope, out-of-scope, and information sources. Read this before reading anything else.

The point of this section is to make explicit what the audit did not look at. Every audit has limits — read-only, no penetration testing, no load testing — and stating them up front prevents the rest of the report from being misread as a complete review. The information sources block also tells you which artifacts the audit was based on, which is the foundation for reproducibility.

What to look for: a clear list of what was excluded, and why. Vague scope is the most common reason audit deliverables become harder to act on later. → Sample: engagement context

03 — Stack inventory

The system, on paper, possibly for the first time. Applications, runtime versions, database versions, OS, host, services map, external integrations.

Most teams that commission an audit do not have a current diagram of their own system. The stack inventory is often the most-shared section of the deliverable for that reason — it gets pasted into hiring docs, vendor questionnaires, and incident post-mortems for years afterward.

What to look for: external integrations explicitly enumerated. The integration that is missing from the diagram is the one that will surprise you in production. → Sample: stack inventory

04 — Risk register

The honest output of the audit. Every finding gets a row: ID, description, severity, business impact, effort estimate, suggested owner, suggested phase.

This is the section the engagement is bought for. Severity is rated on actual operational impact, not on theoretical CVSS scores. Effort is rated honestly — including the ones that are quick wins. Phase ties each row to the 30/60/90-day roadmap, so the register reads as a sequence rather than a list of fears.

What to look for: every row should be actionable. “Documentation is incomplete” is not a finding; “the deploy script is undocumented and only one person can run it” is. → Sample: risk register

05 — Security posture

Authentication hygiene, plugin and dependency CVEs, key rotation, exposed endpoints, environment variable handling. Posture review, not penetration test.

The distinction matters. A pen test asks “can this be broken from outside?” A posture review asks “what is the system’s hygiene relative to known good practice?” The audit answers the second. Pen tests are scoped separately, with explicit authorization, and are not the same engagement.

What to look for: specific findings, with specific fixes. “2FA is not enforced on the admin account for one of the two admin users” beats “auth is weak.” → Sample: security posture

06 — Backups & restore

The backups that exist on paper, and the result of testing one of them on a clean environment.

This is usually the most uncomfortable section. Daily backups exist on most systems we audit. Tested restores do not. The audit always tests at least one — file-level, database-level, and (where possible) full-system — and reports the actual time-to-restore, the actual gaps, and the actual errors that came up. No theoretical recovery objectives.

What to look for: a transcript or log of the restore test, not a description of it. The transcript is the part that proves the test happened. → Sample: backups & restore

07 — Deployment & ops

How code reaches production today. Manual SFTP, direct git pull, CI pipelines, staging parity, monitoring, on-call.

Most operational risk on legacy systems lives here. Not in the code, not in the database, but in how changes are made and observed. A system with clean code and a manual production deploy is more dangerous than a messy one with a tested rollback path. The audit reports both, and weights deployment risk accordingly.

What to look for: the rollback section. If rollback is described in the abstract (“we’d restore from backup”), it is not actually a rollback path. → Sample: deployment & ops

08 — Maintainability

The codebase shape — lines of code, test coverage, CI status, README presence, bus factor.

This is the human-risk section. Bus factor of one means the system depends on a single person’s continued availability. That is a risk like any other — it has a severity, an impact, and a fix. The fix is usually documentation, not hiring; the sole-developer-left-what-now article covers what that looks like in practice.

What to look for: a real bus factor number, with names. “Low documentation coverage” is not a finding; “two of the three deploy steps are only known to the lead developer” is. → Sample: maintainability

09 — AI-assisted documentation snapshot

Where AI helped during the audit. Code-analysis excerpts, system-map output, anomalies the AI flagged that a human then verified.

The audit uses AI as an assistant, not an oracle. Every AI-flagged finding in the report has been read by a human and either confirmed, dismissed, or escalated. The transparency matters: the section makes explicit which observations were AI-derived and what verification step they passed.

What to look for: prompts and outputs you can reproduce. If the AI section reads as a black box, it is a feature, not a deliverable. → Sample: AI-assisted snapshot

10 — 30 / 60 / 90-day roadmap

What to do about the findings, sequenced. Stabilize (days 0–14), Upgrade (days 15–45), Operate (days 45–90). Estimated cost summary by phase.

This is the section that turns the audit from a document into a plan. Stabilize covers the immediate operational risks — the tested-restore gap, the unsupported runtime, the missing rollback. Upgrade covers the framework, language, or hosting modernization. Operate covers the steady state — monitoring, retainer, ongoing care. The cost numbers are real, with a 15% contingency baked in.

What to look for: phase boundaries that match the team’s actual capacity. If the roadmap calls for more parallel work than the team can absorb, it is aspirational rather than usable. → Sample: 30 / 60 / 90-day roadmap

11 — Scope & limitations

What the audit does not cover. Vulnerability scanning, load testing, code-quality refactoring beyond the operational layer, business-logic correctness, performance benchmarking.

This section is short and explicit. It exists to set expectations and to make the audit defensible later — when an unrelated incident occurs and someone asks “did the audit catch this?” the answer is in writing.

What to look for: a contingency note on cost estimates. The audit’s roadmap is honest about being ±15%, not a fixed-price commitment. → Sample: scope & limitations

12 — Appendix

The artifacts that make the audit reproducible: the full risk register CSV, the AI prompt log, the access checklist, the restore-test transcript.

The appendix is where the audit earns its credibility. Anyone with the appendix and access to the system can verify the findings, re-run the AI prompts, repeat the restore test, and audit the audit. That reproducibility is the difference between a deliverable and a slide deck.

What to look for: the access checklist specifically. It is the artifact that survives the engagement and becomes the team’s onboarding document for whoever joins next. → Sample: appendix

How to read the report you receive

Three habits make the audit useful instead of decorative:

• Read in this order: engagement context (02), executive summary (01), risk register (04), roadmap (10). The rest is supporting evidence.
• Treat severity ratings as decisions, not opinions. If a “high” feels like a “medium” to you, the conversation to have with us is which one is wrong — not to discount it silently.
• Share the right sections with the right audiences. The executive summary and roadmap are for stakeholders. The stack inventory is for new hires. The risk register and appendix are for the team doing the work. Different rooms, different excerpts.

The audit is a starting point, not a destination. The goal is to get from “we’re not sure what’s risky” to “here are the seven things we are doing about it, in this order, by these dates.” That is the deliverable. If you want to see it as a complete artifact before deciding, the full sample is here — and requesting an audit for a specific system is the next step when you do. The shape of the engagement, including how it pairs with the Audit service, is on the audit page itself.

If you read the sample and want to start a conversation, contact is the path. The first reply is usually a question about which parts of the report would be most useful for your specific system — most engagements scope themselves through that conversation, not through a fixed template.