Sample audit report
What an audit report looks like.
An excerpt of a modernization audit, in the same seven sections as the real report, so you can see what you’d be handed and who it’s written for.
Example Example — a fictional system, not client work. The company, findings and plan are made up to show the format. The support dates are real.
Order and inventory system
Prepared for a regional distributor: the operations director, the IT lead and finance.
The system as it runs today
Two applications share one database on one virtual machine. A nightly job feeds the accounting system.
Jump to the risks for the server: R1 Jump to the risks for the order and inventory app: R4, R6 Jump to the risks for the customer portal: R2 Jump to the risks for the database: R1, R3 Jump to the risks for the export job: R7
How it fits together
- Staff use the order and inventory app on the office network. Customers use the portal over the public internet.
- Both run under IIS 8.5 on one Windows Server 2012 R2 virtual machine.
- Both read and write the same SQL Server 2012 database on that machine; the portal with full rights.
- A nightly SSIS job exports invoices as a file to the accounting system.
- Releases reach the server as files copied over FTP by hand.
Support status
Every runtime, framework and major dependency, and whether it still gets security updates.
| Component | Used for | Status | Security updates | Risk |
|---|---|---|---|---|
| Windows Server 2012 R2 | The one virtual machine everything runs on | Ended | Extended support ended 10 October 2023. Paid Extended Security Updates, where bought, ran to 13 October 2026. | R1 |
| IIS 8.5 | Web server for the app and the portal | Ended | Part of Windows Server 2012 R2, so it shares the same dates. | R1 |
| SQL Server 2012, with SSIS | Orders, stock and customers; the nightly export | Ended | Extended support ended 12 July 2022, and the paid Extended Security Updates ended in July 2025. | R1 |
| PHP 5.6 | The customer portal | Ended | End of life 31 December 2018. No security fixes since. | R2 |
| .NET Framework 4.6.2 | Runtime for the order and inventory app | Ending | Support ends 12 January 2027. Version 4.8.1 is supported for as long as the Windows version it runs on. | R6 |
| ASP.NET Web Forms | Every screen of the order and inventory app | No way forward | Runs only on .NET Framework. Modern .NET doesn’t include it, so screens must be rebuilt to move on. | R6 |
| Two reporting libraries | Pick lists and invoices as PDF | Unmaintained | No release from either in years; one has a published vulnerability. | R6 |
Dates from the vendors’ published lifecycles: Microsoft for Windows Server, SQL Server and .NET Framework; php.net for PHP.
Changing it
How releases happen, what tests exist, and where a small change tends to break something else.
- Releases
- One developer copies changed files to the server over FTP, after hours. There’s no record of what went out when. Going back means finding the previous files in a folder on the same server. Readiness check: releases by hand
- Tests
- None automated. The operations team clicks through order entry the morning after a release. Readiness check: few or no tests
- Fragile areas
- Pricing rules sit in the code behind one large page,
OrderEntry.aspx. Stored procedures are shared by the app and the portal, so a change for one breaks the other. The export reads columns by position. Readiness check: slow, risky changes
Access and recovery
Who can reach what, where secrets live, and whether a backup has ever been restored.
- Who can reach what
- Three staff and a former contractor share one Windows administrator account. Remote Desktop answers from the internet. The portal signs in to the database with full rights.
- Secrets
- Database passwords sit in plain text in
web.configand the portal’s config file. The FTP password is in a shared spreadsheet. - Backups
- The database is backed up nightly to a second disk on the same server, and copied weekly to a storage box in the office. Application files and server settings aren’t backed up. No backup has ever been restored. Readiness check: untested backups
Knowledge
What is written down, and what currently lives in one person’s head.
Written down
- A network diagram, several years out of date
- Setup notes for the nightly export
- The server’s address and the FTP login
In one person’s head
- Which customers get which price exceptions, and why
- How to re-run the export after it fails
- How the portal is deployed (the contractor who built it)
- Which stored procedures the portal depends on
Readiness check: no current documentation; knowledge gone
Example · fictional
Risks, ranked
Each in plain language, with what it would cost the business if it happened. Ranked by likelihood and impact together.
| ID | Risk | Likelihood | Impact on the business | Recommended action |
|---|---|---|---|---|
| R1 | The server and the database get no security fixes, and Remote Desktop is open to the internet.Readiness check: hosting nobody could rebuild | High | Severe A known, unpatched hole is the easiest way in. A cyber-insurance renewal or a customer’s security questionnaire would flag it. | Close Remote Desktop to the internet this month. Move to supported Windows Server and SQL Server in stage 1. |
| R2 | The customer portal runs on PHP 5.6 and signs in to the database with full rights.Readiness check: unsupported runtime | High | Severe A break-in through the portal would reach every customer, price and order, not only the portal’s own pages. | Give the portal its own login, limited to what it shows and the orders it places. Replace the portal in stage 2. |
| R3 | Backups have never been restored, and every copy but a weekly one sits on the same server.Readiness check: untested backups | Medium | Severe A failed disk or ransomware could lose up to a week of orders and stock counts, and stop shipping until the server is rebuilt from memory. | Restore last night’s backup to a separate machine now. Copy backups off the server daily, and write down the restore. |
| R4 | Releases are files copied over FTP by hand, with no automated tests and no record of what changed.Readiness check: releases by hand; few or no tests | High | High A bad release can stop order entry during business hours, with no quick way back to the version that worked. | Put the code in version control, script the release with a one-step rollback, and add tests around pricing and order totals first. |
| R5 | Pricing exceptions and the SSIS recovery steps live in one person’s head.Readiness check: no current documentation | Medium | High If that person is away at month end, invoices can’t be fixed or re-sent, and price changes wait for their return. | Record the pricing rules and a runbook for the nightly export, checked by someone else following them. |
| R6 | .NET Framework 4.6.2 support ends 12 January 2027, Web Forms can’t move to modern .NET as it is, and two libraries are unmaintained.Readiness check: unmaintained dependencies | Certain | Moderate After that date the app’s runtime gets no security fixes. Each new Web Forms screen adds to what must be rebuilt later. | Retarget the app to .NET Framework 4.8.1 in stage 1, a contained change. Decide on moving off Web Forms after stage 2. |
| R7 | The nightly export to accounting fails without telling anyone. | Medium | Moderate Missing invoices surface at month-end close, when they hold up the books and take the longest to trace. | Alert on failure, and add a morning check that totals match on both sides. |
Example · fictional
The staged plan
What to keep, upgrade or replace, in order of risk and value. The first stage is scoped; later stages are scoped before they start.
Keep
- The order workflow and its data model
- Order, stock and customer data
- The accounting system and the file it receives
Upgrade
- Windows Server and SQL Server, to supported versions
- .NET Framework 4.6.2 to 4.8.1
- The SSIS export, moved across with alerting added
Replace
- The PHP 5.6 customer portal
- FTP releases, with a scripted release and rollback
- The shared admin account, with named accounts
Stage 1 · Scoped
Make it recoverable and supported
In scope
- A tested restore, timed, on a separate machine; daily copies off the server R3
- Remote Desktop closed to the internet; named accounts; secrets out of config files R1
- A new virtual machine on supported Windows Server and SQL Server, with the export moved across and alerting added R1 R7
- Code in version control, a scripted release with rollback, and tests around pricing and order totals R4
- The app retargeted to .NET Framework 4.8.1 R6
- Runbooks for the export and the restore; the pricing rules written down R5
Not in this stage
- Changes to how orders are entered
- The customer portal, beyond its database login
- Moving off Web Forms
Done when
- Someone other than the author has restored the system from the runbook
- A release can be rolled back in one step
Stage 2 · Scoped before it starts
Replace the customer portal
Rebuilt on a supported stack, reading through its own narrow interface instead of the shared stored procedures. R2
Decision point
Order entry: keep on 4.8.1, or move off Web Forms
With tests in place, decide whether to rebuild order entry on modern .NET screen by screen, or keep it on .NET Framework 4.8.1 for now. Either way is a decision you can make between stages. R6
End of excerpt · The real report also holds the evidence behind each finding
Take the readiness check for your system How a modernization runs
Start a project
Want this for your system?
Tell us what it runs on and what worries you about it. We reply within one business day, with questions or a time to talk.
Pittsburgh, PA · Since 2015 · First step: a 30-minute call