Sample report
What a software assessment report looks like
This is a shortened example of the report you receive at the end of an assessment. The company, its system and every finding are fictional, written to show the format. No client information was used.
- Client (fictional)
- Northwind Freight B.V.
- System
- Customer portal and invoicing
- Situation
- In-house developer has left
1. Executive summary
The short version
The portal works and is used daily by around 400 customers. The code is readable and can be maintained by a new team. However, three risks need attention before ongoing support starts: backups have never been tested, two service keys are exposed in the code, and the web framework no longer receives security updates.
Recommendation: a short stabilisation phase addressing findings F1–F3, followed by a support plan. A rebuild is not recommended at this stage.
2. Scope
What was and was not reviewed
In scope
- Code repository of the portal and invoicing module
- Hosting server and database configuration
- Deployment process
- Third-party services: email, payments
Out of scope
- Penetration testing
- The separate warehouse system the portal reads from
- Load testing
3. Findings
Technical findings and risk levels
Every finding comes with the evidence behind it in the full report. Here: the summary table.
| ID | Area | Finding | Risk | Recommendation |
|---|---|---|---|---|
| F1 | Infrastructure | Database backups run nightly but have never been restored. Backups are stored on the same server as the database. | High | Move backups to separate storage and perform a test restore. Repeat the restore test quarterly. |
| F2 | Security | API keys for the email and payment services are committed in the repository history. | High | Rotate both keys, move secrets to environment configuration and remove them from history. |
| F3 | Dependencies | The web framework is two major versions behind and no longer receives security updates. | High | Plan a staged upgrade. Interim: apply the available patches for the two known vulnerabilities. |
| F4 | Deployment | Releases are copied to the server by hand by one person. There is no record of which version is live. | Medium | Introduce an automated deployment pipeline with versioned releases and a rollback step. |
| F5 | Errors and logging | Errors are written to a log file that is overwritten daily. Nobody is alerted when the app fails. | Medium | Add error tracking with alerts, and keep logs for at least 30 days. |
| F6 | Tests | There are no automated tests. The invoicing module, which changes most often, is the riskiest to modify. | Medium | Add tests around invoicing before any further changes are made to it. |
| F7 | Documentation | There is no documentation beyond a short setup note. Three scheduled jobs are undocumented. | Low | Document the architecture, the scheduled jobs and the deployment as part of the takeover. |
High
Could cause data loss, a security incident or a prolonged outage. Address before or at the start of support.Medium
Makes failures more likely or harder to fix. Address in the first months of support.Low
Slows down maintenance but carries little immediate risk. Address as part of normal work.
4. Recommendations
Prioritised stabilisation plan
Before support starts
F1 test restore and separate backup storage. F2 rotate and remove exposed keys. F3 patch known vulnerabilities and schedule the framework upgrade.First three months
F4 automated deployments with rollback. F5 error tracking and alerts. F6 tests around invoicing.Ongoing
F7 documentation, completed framework upgrade, regular dependency updates under the support plan.
5. Further investigation
What the assessment could not answer
Recommended follow-up
- The warehouse system the portal reads from was out of scope; its stability directly affects the portal
- Licence terms for the PDF component used in invoicing could not be confirmed